Re: [bug #30131] GSMimeDocument rawMimeData or some memory code broken

[Richard Frith-Macdonald]

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.