[Stackless] Bug Report: Bus error on Mac OS X Snow Leopard (x86_64)

Kristján Valur Jónsson kristjan at ccpgames.com
Mon Dec 13 07:53:23 CET 2010


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: stackless-bounces at stackless.com [mailto:stackless-bounces at stackless.com] On Behalf Of Daniel Norberg
Sent: Monday, December 06, 2010 6:55
To: stackless at stackless.com
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
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless




More information about the Stackless mailing list