Re: Crashing in _Block_release

[David Chisnall]

This looks like a double-free.  Can you try running with valgrind or with 
whatever memory debugging facilities your system malloc provides turned on?

David

On 29 Feb 2012, at 23:14, Jens Alfke wrote:

> I rebuilt libobjc2 without optimizations; now I can get a backtrace and more 
> info when it crashes.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000021 in ?? ()
> (gdb) bt
> #0  0x00000021 in ?? ()
> #1  0x00b7608f in _Block_object_dispose (object=0x8193990, flags=8) at 
> blocks_runtime.m:208
> #2  0x008b1f29 in __destroy_helper_block_ () at 
> vendor/MYUtilities/MYBlockUtils.m:54
> #3  0x00b76335 in _Block_release (src=0x81b8368) at blocks_runtime.m:299
> #4  0x0024576c in -[GSBlock release] (self=0x81b8368, _cmd=0x721f18) at 
> GSBlocks.m:81
> #5  0x002c7dc1 in -[NSAutoreleasePool emptyPool] (self=0x8106f64, 
> _cmd=0x721ea8) at NSAutoreleasePool.m:658
> (gdb) frame 1
> #1  0x00b7608f in _Block_object_dispose (object=0x8193990, flags=8) at 
> blocks_runtime.m:208
> 208                                                   src->byref_dispose(src);
> (gdb) print *src
> $1 = {isa = 0x1, forwarding = 0x8193990, flags = 0, size = 20, byref_keep = 
> 0x8b3001 <_AssertAbstractMethodFailed+193>, byref_dispose = 0x21}
> 
> So the block has a byref_dispose function pointer with a highly bogus value.
> 
> I’m reassured that I’m running with the right libobjc2, because recompiling 
> it with -O0 made a difference at runtime. I’m still a little confused by the 
> fact that gnustep-base seems to have its own different copy of the runtime in 
> Source/ObjectiveC2. I wonder if they have incompatible header files declaring 
> block layout?
> 
> —Jens
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


-- Sent from my PDP-11