I am not able to reproduce the problem. I've tried the latest "release27-maint" branch. I´ve also tried the latest release26-maint branch and a version synced to revision 79133, which is the revision when the tags/python-2.65 was created. Notice that in that revision, there is no line (scheduling.c:942) Is it possible you are using another revision? Can you check your line numbers? K
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Norberg Sent: Monday, December 06, 2010 6:55 To: [email protected] Subject: [Stackless] Bug Report: Bus error on Mac OS X Snow Leopard (x86_64) Hi, I've discovered a possible bug in Stackless 2.6 on Mac OS X Snow Leopard. Running the following script using a x86_64 stackless on Mac OS X Snow Leopard produces a bus error. import stackless stackless.tasklet(lambda:None)().remove() Compiling stackless using CC="gcc -arch i386" makes the problem go away so it seems to be x86_64 specific. I'm using latest stackless 2.65 from svn: $ svn checkout http://svn.python.org/projects/stackless/tags/python-2.65/ Checked out revision 87092. Running valgrind produces the following: $ valgrind --tool=memcheck --dsymutil=yes --suppressions=Misc/valgrind-python.supp ./python.exe -c "import stackless stackless.tasklet(lambda:None)().remove()" ==6320== Memcheck, a memory error detector ==6320== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==6320== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==6320== Command: ./python.exe -c import\ stackless ==6320== stackless.tasklet(lambda:None)().remove() ==6320== --6320-- run: /usr/bin/dsymutil "./python.exe" ==6320== Use of uninitialised value of size 8 ==6320== at 0x1000BBB23: slp_schedule_task (scheduling.c:942) ==6320== by 0x100E3A74F: ??? ==6320== by 0x100BE1A4F: ??? ==6320== ==6320== Use of uninitialised value of size 8 ==6320== at 0x1000BBB2F: slp_schedule_task (scheduling.c:942) ==6320== by 0x100E3A74F: ??? ==6320== by 0x100BE1A4F: ??? ==6320== ==6320== Use of uninitialised value of size 8 ==6320== at 0x1000BBB42: slp_schedule_task (scheduling.c:943) ==6320== by 0x100E3A74F: ??? ==6320== by 0x100BE1A4F: ??? ==6320== ==6320== Use of uninitialised value of size 8 ==6320== at 0x1000BB672: slp_schedule_task (scheduling.c:952) ==6320== by 0x100BE1A4F: ??? ==6320== ==6320== Use of uninitialised value of size 8 ==6320== at 0x100E3A750: ??? ==6320== by 0x100BE1A4F: ??? ==6320== ==6320== Conditional jump or move depends on uninitialised value(s) ==6320== at 0x100E3A758: ??? ==6320== by 0x100BE1A4F: ??? ==6320== vex amd64->IR: unhandled instruction bytes: 0x63 0x68 0x3A 0x20 0x6E 0x6F ==6320== valgrind: Unrecognised instruction at address 0x100e3a704. ==6320== Your program just tried to execute an instruction that Valgrind ==6320== did not recognise. There are two possible reasons for this. ==6320== 1. Your program has a bug and erroneously jumped to a non-code ==6320== location. If you are running Memcheck and you just saw a ==6320== warning about a bad jump, it's probably your program's fault. ==6320== 2. The instruction is legitimate but Valgrind doesn't handle it, ==6320== i.e. it's Valgrind's fault. If you think this is the case or ==6320== you are not sure, please let us know and we'll try to fix it. ==6320== Either way, Valgrind will now raise a SIGILL signal which will ==6320== probably kill your program. ==6320== ==6320== Process terminating with default action of signal 4 (SIGILL) ==6320== Illegal opcode at address 0x100E3A704 ==6320== at 0x100E3A704: ??? ==6320== by 0x100BE1A4F: ??? ==6320== ==6320== HEAP SUMMARY: ==6320== in use at exit: 2,789,843 bytes in 1,796 blocks ==6320== total heap usage: 8,656 allocs, 6,860 frees, 8,619,382 bytes allocated ==6320== ==6320== LEAK SUMMARY: ==6320== definitely lost: 0 bytes in 0 blocks ==6320== indirectly lost: 0 bytes in 0 blocks ==6320== possibly lost: 63,968 bytes in 133 blocks ==6320== still reachable: 2,725,875 bytes in 1,663 blocks ==6320== suppressed: 0 bytes in 0 blocks ==6320== Rerun with --leak-check=full to see details of leaked memory ==6320== ==6320== For counts of detected and suppressed errors, rerun with: -v ==6320== Use --track-origins=yes to see where uninitialised values come from ==6320== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 1340 from 45) Illegal instruction Is there some more information I can provide or some other way I can help out with resolving this issue? Thanks, Daniel _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
