Re: [Pyobjc-dev] Re: debugging pyobjc

[Ronald O. <ous...@ci...>]

On 22 jan 2004, at 17:21, Michael Hudson wrote:

> Michael Hudson <mw...@py...> writes:
>
>> I'm vaguely trying to track down a bug in recent versions of pygame on
>> MacOS X, which now uses PyObjC.  So, after much wailing and gnashing
>> of teeth (see pythonmac-sig) I have a debugging framework install of
>> Python, and seem to have built pyobjc against it.
>>
>> 1) PyObjC's setup.py seems to unconditionally pass -O3 to the
>>    compiler.  This is, um, contrary to the spirit of a debug build.
>>    What's wrong with the value of CFLAGS you get by default (from
>>    $(prefix)/lib/python$(VERSION)/config/Makefile)?

I'll change those, the defaults should be good enough.

>>
>> 2) Stuff like this isn't encouraging:
>>
>> [mwh@pc150 mwh]$  
>> /Library/Frameworks/DbgPython.framework/Versions/Current/bin/ 
>> python2.3
>> Python 2.3.3 (#1, Jan 22 2004, 14:18:14)
>> [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import Foundation
>> [54592 refs]
>>>>>
>> [54592 refs]
>> Debug memory block at address p=0x44ead0:
>>     40834 bytes originally requested
>>     The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
>>         at p-4: 0x00 *** OUCH
>>         at p-3: 0x44 *** OUCH
>>         at p-2: 0x00 *** OUCH
>>         at p-1: 0x01 *** OUCH
>>     Because memory is corrupted at the start, the count of bytes  
>> requested
>>        may be bogus, and checking the trailing pad bytes may segfault.
>>     The 4 pad bytes at tail=0x458a52 are not all FORBIDDENBYTE (0xfb):
>>         at tail+0: 0x00 *** OUCH
>>         at tail+1: 0x20 *** OUCH
>>         at tail+2: 0x7c *** OUCH
>>         at tail+3: 0x08 *** OUCH
>>     The block was made by call #44482497 to debug malloc/realloc.
>>     Data at p: 40 40 3a 40 00 00 00 00 ... 03 a6 bb c1 ff f8 4e 80
>> Fatal Python error: bad leading pad byte
>>
>> Am I in new territory here?
>
> Actually I'm seeing runPyObjCtests (or whatever that script's called)
> dump core when run against today's CVS built against a release Python.
> So I think there may be real problems here.

Do you by any change have a machine without a G4 processor? The  
setup.py also sets some flags for G4 specific compilation. Those will  
also be removed.

I'm currently rebuilding PyObjC to check for problems. One thing you  
might try is removing the existing PyObjC installation before  
installing a new one (if you have one installed). In my quest (sp?) for  
faster loading times I've moved some of the extensions.

Ronald