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 <[EMAIL PROTECTED]> 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. > _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
