On 15 Jun 2010, at 12:06, David Wetzel wrote:
>
> Follow-up Comment #1, bug #30131 (project gnustep):
>
> setenv NSZombieEnabled 1
>
> helps a bit:
>
> (gdb) up
> #1 0x00007f7ffd9326db in -[GSMimeDocument rawMimeData:]
> (self=0x7f7fe1ddb830, _cmd=0x7f7ffdba2160, isOuter=1 ' 01') at GSMime.m:5437
> 5437 [partData addObject: [part rawMimeData: NO]];
> (gdb) po [part rawMimeData: 1]
> <NSZombie: 0x7f7fe1ddde10>
> (gdb) po part
> GSMimeDocument <e1de65a0> -
> (
> "GSMimeHeader <e1ddde50> -
> name: mime-version
> value: 1.0
> params: {}
> ",
> "GSMimeHeader <e1ddd250> -
> name: content-type
> value: multipart/alternative
> params: {boundary = "VDbR17nYvf6Iu9cM0Rrf6QAAAAE="; }
> "
> )
> Document content -
> ("GSMimeDocument <e1de6630> -
> (
> "GSMimeHeader <e1ddd0d0> -
> name: content-type
> value: text/plain
> params: {}
> "
> )
> Document content -
> hey dave
> test test test
> ")
> (gdb) po [part rawMimeData:0]
> <NSZombie: 0x7f7fe1df7590>
> (gdb)
If I undersatand this correctly, your lines 'po [part rawMimeData: 1]' and 'po
[part rawMimeData:0]' both call -rawMimeData: and both return a deallocated
object.
Now, -rawMimeData: allocates an autoreleased NSMutableData object, creates a
new autorelease pool, puts information into the data, releases the autoerlease
pool (to get rid of temporary objects used while building the data), and
returns the data.
It's hard to see how the result can be deallocated.
1. perhaps the gdb 'po' command is creating/destroying an autorelease pool
which destroys the return value
2. perhaps the compiler is re-ordering . code so that the autorelease pool is
created before the data object
3. perhaps the autorelease is messing up and deallocating objects in the wrong
pool
None of this seems at all likely. I think we need a reproducible testcase to
debug this.
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
