Thread: [Pyobjc-dev] debugging pyobjc
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Michael H. <mw...@py...> - 2004-01-22 14:59:02
|
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)?
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?
Cheers,
mwh
--
This proposal, if accepted, will probably mean a heck of a lot of
work for somebody. But since I don't want it accepted, I don't
care. -- Laura Creighton, PEP 666
|
|
From: Michael H. <mw...@py...> - 2004-01-22 16:21:49
|
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)?
>
> 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.
Cheers,
mwh
--
Enlightenment is probably antithetical to impatience.
-- Erik Naggum, comp.lang.lisp
|
|
From: Ronald O. <ous...@ci...> - 2004-01-22 19:37:30
|
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 |
|
From: Ronald O. <ous...@ci...> - 2004-01-22 22:17:34
|
>> 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. >> The pyobjc repository is affected by the problem described in the SF status update titled 'Project CVS Service - 2004-01-22 13:34:40'. Basically our CVS repository contains some old files. I noticed this why trying to update my local tree and have filed a support request. Ronald |
|
From: Michael H. <mw...@py...> - 2004-01-23 10:24:53
|
Ronald Oussoren <ous...@ci...> writes:
> 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.
Ta.
>>>
>>> 2) Stuff like this isn't encouraging:
>>>
[snippety]
>>>
>>> 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?
Yes...
> The setup.py also sets some flags for G4 specific compilation. Those
> will also be removed.
Thanks. I thought I'd hacked them out too, but maybe not. I did get
some "Illegal Instruction" crashes as well, which was perhaps a
clue...
> 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.
I think I may have made this mistake as well yesterday.
Last night I built a fresh PyObjC and actually used it successfully,
so the problems can't be that severe. I didn't dare run the tests,
though :-) (I had a bad day wrt computers yesterday).
Cheers,
mwh
--
40. There are two ways to write error-free programs; only the third
one works.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X