Hi all, I did a bit of detective work this evening, and found the following. The reason Eric's cron job is no longer showing results for stackless builds is that we broke old-stackless builds of PyPy by adding resume point operations (for unpickling tasklets). They end up as OP_RESUME_STATE_CREATE() macro calls in genc! Argh. Either with fix by somehow detecting in the _stackless module if we are being compiled with old- or new-stackless. Or we don't care any more about the old-stackless and declare it dead for the purpose of compiling PyPy. I also found out that the test summary page at http://snake.cs.uni-duesseldorf.de/pypytest/summary.html was doing a great job at hiding the fact that the tests no longer ran to the end, and that, for more than two weeks now. Either test_ee in pyllvm was getting a SIGIOT signal (people who ever heard about this signal, raise your hand), or test_wrapping was segfaulting (unreproductably - fun). I still have no clue why test_wrapping occasionally segfaults. In any case I fixed the output by considering abnormal termination as a failure. It shows up now at the beginning of the failures. I also modified the misleading '.', which previously only meant 'this test did not fail in that revision' -- e.g. because they were not run at all :-/ Now, a '.' really means 'known to have passed in that revision'. Otherwise you can get an 's', or a ' ' if the test wasn't run at all. Note that before the 12th of June, the necessary information was not collected by the run, so all non-failures there show up as ' ' even if the test was actually run. A bientot, Armin.
Armin Rigo wrote:
...
I also found out that the test summary page at http://snake.cs.uni-duesseldorf.de/pypytest/summary.html was doing a great job at hiding the fact that the tests no longer ran to the end, and that, for more than two weeks now. Either test_ee in pyllvm was getting a SIGIOT signal (people who ever heard about this signal, raise your hand), or test_wrapping was segfaulting (unreproductably - fun). I still have no clue why test_wrapping occasionally segfaults. ...
I reported a segfault some time ago (python2.4 specific), of which you can read in the archives, but no one seemed to be interested and I didn't want to push it. My post was about compilemodule.py, but this might very well be related since they use the same code quite the same way I think. The segfaulting stopped at some point, but if you try a revision around the time that I sent my post (11.5), you might be able to reproduce it. The segfaulting itself seemed to me as a bug in python, but since it didn't happen with 2.5 (some other error did though =), I didn't see it as so important. Maybe I should've pushed it harder =). Just say if I'm totally off the course, Elmo
Hi Elmo, On Mon, Jun 19, 2006 at 01:36:54AM +0300, Elmo M?ntynen wrote:
I also found out that the test summary page at http://snake.cs.uni-duesseldorf.de/pypytest/summary.html was doing a great job at hiding the fact that the tests no longer ran to the end, and that, for more than two weeks now. Either test_ee in pyllvm was getting a SIGIOT signal (people who ever heard about this signal, raise your hand), or test_wrapping was segfaulting (unreproductably - fun). I still have no clue why test_wrapping occasionally segfaults. ...
I reported a segfault some time ago (python2.4 specific), of which you can read in the archives, but no one seemed to be interested and I didn't want to push it. My post was about compilemodule.py, but this might very well be related since they use the same code quite the same way I think.
No, test_wrapping is about something different than what compilemodule.py uses. The kind of wrapping tested here is only used by external tools developed by Christian Tismer, which he meanwhile checked in as pypy/translator/rool/raymond.py. As I have no full clue about what test_wrapping does (and it uses names like "test_asd", which makes it crystal clear what the intent of the test is), I think I can live with this crash for now. Sorry for not having come back to you about the segfault you reported, I could never reproduce it myself...
The segfaulting itself seemed to me as a bug in python, but since it didn't happen with 2.5 (some other error did though =), I didn't see it as so important. Maybe I should've pushed it harder =).
So what is the current status: does compilemodule.py _demo work for you? On several Python versions? A bientot, Armin
Armin Rigo wrote:
Hi Elmo,
On Mon, Jun 19, 2006 at 01:36:54AM +0300, Elmo M?ntynen wrote:
I also found out that the test summary page at http://snake.cs.uni-duesseldorf.de/pypytest/summary.html was doing a great job at hiding the fact that the tests no longer ran to the end, and that, for more than two weeks now. Either test_ee in pyllvm was getting a SIGIOT signal (people who ever heard about this signal, raise your hand), or test_wrapping was segfaulting (unreproductably - fun). I still have no clue why test_wrapping occasionally segfaults. ...
I reported a segfault some time ago (python2.4 specific), of which you can read in the archives, but no one seemed to be interested and I didn't want to push it. My post was about compilemodule.py, but this might very well be related since they use the same code quite the same way I think.
No, test_wrapping is about something different than what compilemodule.py uses. The kind of wrapping tested here is only used by external tools developed by Christian Tismer, which he meanwhile checked in as pypy/translator/rool/raymond.py. As I have no full clue about what test_wrapping does (and it uses names like "test_asd", which makes it crystal clear what the intent of the test is), I think I can live with this crash for now.
Sorry for not having come back to you about the segfault you reported, I could never reproduce it myself...
The segfaulting itself seemed to me as a bug in python, but since it didn't happen with 2.5 (some other error did though =), I didn't see it as so important. Maybe I should've pushed it harder =).
So what is the current status: does compilemodule.py _demo work for you? On several Python versions?
2.3 seems to work nicely, 2.4 segfaults (?! I thought it worked again), which I'll try to reproduce with different machine (I'll report soon): ... [translation:info] with policy: pypy.objspace.cpy.ann_policy.CPyAnnotatorPolicy ... segfault and latest 2.5 works. This might just be something on my end, but any pointers on what might be wrong would be useful. A small complaint about py.test: a segfaulting test crashes py.test with EOFError and with an older rev of 2.5 compilemodule.py _demo errored and I got a pdb prompt, but py.test test_compilemodule.py reported a success nonetheless!?
Hi Elmo, On Thu, Jun 22, 2006 at 02:20 +0300, Elmo Mäntynen wrote:
A small complaint about py.test: a segfaulting test crashes py.test with EOFError and with an older rev of 2.5 compilemodule.py _demo errored and I got a pdb prompt, but py.test test_compilemodule.py reported a success nonetheless!?
Maybe the test doesn't do the same test as the direct invocation of the compilemodule.py does? Either way, i added a feature issue (https://codespeak.net/issue/pypy-dev/issue233) so that py.test allows more robust test modes. Thanks for the comment! It has been an issue in the past but its severity grew with more and more tests being able to segfault. best, holger
holger krekel wrote:
Hi Elmo,
On Thu, Jun 22, 2006 at 02:20 +0300, Elmo Mäntynen wrote:
A small complaint about py.test: a segfaulting test crashes py.test with EOFError and with an older rev of 2.5 compilemodule.py _demo errored and I got a pdb prompt, but py.test test_compilemodule.py reported a success nonetheless!?
Maybe the test doesn't do the same test as the direct invocation of the compilemodule.py does?
Actually, they seem to do the very same thing: they call compilemodule('_demo'). If they weren't doing the same thing, would the test be testing the right thing? Anyway, I happened to update my python2.5 and don't have any record of what happened, so I can't be sure about it.
Either way, i added a feature issue (https://codespeak.net/issue/pypy-dev/issue233) so that py.test allows more robust test modes. Thanks for the comment! It has been an issue in the past but its severity grew with more and more tests being able to segfault.
best,
holger
Hi Elmo, On Thu, Jun 22, 2006 at 02:20:54AM +0300, Elmo M?ntynen wrote:
2.3 seems to work nicely, 2.4 segfaults (?! I thought it worked again), which I'll try to reproduce with different machine (I'll report soon): ... [translation:info] with policy: pypy.objspace.cpy.ann_policy.CPyAnnotatorPolicy ... segfault and latest 2.5 works.
We'd need some much more precise info about this to be able to do anything. Which version of CPython is that precisely, which PyPy revision, which OS? Can you also please paste the whole output before the segfault? If you manage to get a error and a pdb prompt with another Python version, can you also please paste the whole output here, together with the exact CPython version number? Thanks! Armin
Elmo Mäntynen wrote:
holger krekel wrote:
Hi Elmo,
On Thu, Jun 22, 2006 at 02:20 +0300, Elmo Mäntynen wrote:
A small complaint about py.test: a segfaulting test crashes py.test with EOFError and with an older rev of 2.5 compilemodule.py _demo errored and I got a pdb prompt, but py.test test_compilemodule.py reported a success nonetheless!?
Maybe the test doesn't do the same test as the direct invocation of the compilemodule.py does?
Actually, they seem to do the very same thing: they call compilemodule('_demo'). If they weren't doing the same thing, would the test be testing the right thing? Anyway, I happened to update my python2.5 and don't have any record of what happened, so I can't be sure about it.
Actually, there's one difference: try: driver.proceed(['compile_c']) except SystemExit: raise except: if not interactive: raise debug(driver) raise SystemExit(1) return driver.cbuilder.c_ext_module where interactive is True for the direct invocation. Could this just be the fault of a broken CPython interpreter?
Armin Rigo wrote:
Hi Elmo,
On Thu, Jun 22, 2006 at 02:20:54AM +0300, Elmo M?ntynen wrote:
2.3 seems to work nicely, 2.4 segfaults (?! I thought it worked again), which I'll try to reproduce with different machine (I'll report soon):
[cbuild:execute] cc -O2 -pthread -I/usr/include/python2.4 -c ctypesplatcheck_0.c -o ctypesplatcheck_0.o [cbuild:execute] cc -pthread /tmp/usession-20/ctypesplatcheck_0.o -lm -lpthread -o /tmp/usession-20/ctypesplatcheck_0 [cbuild:execute] cc -O2 -pthread -c ctypesplatcheck_1.c -o ctypesplatcheck_1.o [cbuild:execute] cc -pthread /tmp/usession-20/ctypesplatcheck_1.o -lm -lpthread -o /tmp/usession-20/ctypesplatcheck_1 [translation:info] Annotating&simplifying... [translation:info] with policy: pypy.objspace.cpy.ann_policy.CPyAnnotatorPolicy Segmentation fault
We'd need some much more precise info about this to be able to do anything. Which version of CPython is that precisely, which PyPy revision, which OS? Can you also please paste the whole output before the segfault?
CPython: Python 2.4.4c0 (#2, Jun 14 2006, 22:35:41) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-4)] on linux2 OS: Debian Etch, linux 2.6.15 Pypy: latest revision to be continued...
If you manage to get a error and a pdb prompt with another Python version, can you also please paste the whole output here, together with the exact CPython version number?
When I tried debugging this, I had hunted down the particular place where the segfault happens, and there was nothing, meaning that there wasn't anything particular that seemed like something that CPython wasn't made to handle, just some normal looking code. The gist of all this is that it seemed to me that the segfault is a plain bug in CPython, just a more obscure one that shows up with the wuite massive pypy machinery.
participants (3)
-
Armin Rigo -
Elmo Mäntynen -
hpk＠trillke.net