Re: SIGSEGV with 2 apps with latest SVN

[Fred Kiefer]

Here less information really would have been more. As we are not trying
to debug memory issues in your X server it would have been sufficient to
 look at the following lines:

==12460== Process terminating with default action of signal 11 (SIGSEGV)
==12460==  Bad permissions for mapped region at address 0x80E42EA
==12460==    at 0x434576D: _i_NSView__setFrame_ (NSView.m:1101)
==12460==    by 0x804D6B0: (within
/usr/GNUstep/System/Applications/GWorkspace.app/GWorkspace)

==12926== Invalid read of size 4
==12926==    at 0x4A8E5CD: objc_msg_lookup (in /usr/lib/libobjc.so.2.0.0)
==12926==    by 0x8050CED: _i_ScrubbingBar__drawRect_ (ScrubbingBar.m:87)
==12926==    by 0x42739D0:
_i_NSView__displayRectIgnoringOpacity_inContext_ (NSView.m:2440)
==12926==    by 0x42739D0:
_i_NSView__displayRectIgnoringOpacity_inContext_ (NSView.m:2440)
==12926==    by 0x4273460: _i_NSView__displayRectIgnoringOpacity_
(NSView.m:2353)
==12926==    by 0x8049CE0: (within
/usr/GNUstep/Local/Applications/MplayerGS.app/MplayerGS)
==12926==  Address 0xE8243489 is not stack'd, malloc'd or (recently) free'd
==12926==
==12926== Process terminating with default action of signal 11 (SIGSEGV)
==12926==  Access not within mapped region at address 0xE8243489
==12926==    at 0x4A8E5CD: objc_msg_lookup (in /usr/lib/libobjc.so.2.0.0)
==12926==    by 0x8050CED: _i_ScrubbingBar__drawRect_ (ScrubbingBar.m:87)
==12926==    by 0x42739D0:
_i_NSView__displayRectIgnoringOpacity_inContext_ (NSView.m:2440)
==12926==    by 0x42739D0:
_i_NSView__displayRectIgnoringOpacity_inContext_ (NSView.m:2440)
==12926==    by 0x4273460: _i_NSView__displayRectIgnoringOpacity_
(NSView.m:2353)
==12926==    by 0x8049CE0: (within
/usr/GNUstep/Local/Applications/MplayerGS.app/MplayerGS)

We really are dealing with an access to memory that either was never
allocated or already freed. The most likely case is that some subview
was released, but is still in the list of subviews of another view and
when accessed it produces these segmentation faults. In the second
program I am almost sure this is the cause of the problem.
As your SrubbingBar is not handled explicitly in your code the only
other problem I could think of is that it is not handled properly by the
 Gorm decoding. (This may be far fetched, but it is currently the only
new idea I came up with)
What you could try to do is run the application with a break point in
[ScrubbingBar dealloc] and see where this gets called from. If it
doesn't get called then my whole theory is worthless and we have to
think anew. And all of this wont help to solve your first issue. I am
totally at loss there.

Fred



Charles philip Chan wrote:
> Fred Kiefer <fredkiefer@gmx.de> writes:
>> Could you try to run your application with valgrind and/or GNUstep
>> memory debugging enabled? I know that you are familiar with that, as
>> you already had to use it for the last problem I caused :-(
> 
> Here are the log done with Valgrind:
> 
> ------------------------------------------------------------------------
> 
> 
> This is again a fresh installation with the old GNUstep tree moved out
> of the way. I am using these versions:
> 
>    Base: r27136
>    GUI: r27136
>    Back: r27110
> 
> with the art backend.
>