The _firstResponder object in GormDocument is a proxy object which is used to allow the developer to make a connection with a target of nil so that when the application is run and the connection is established it will cause the method [NSApplication sendAction:to:from:] to search the responder chain for the first object which responds to the action which was specified.
So it makes sense that it wouldn't match any of the subviews. GC On Fri, Feb 22, 2013 at 3:50 PM, Fred Kiefer <[email protected]> wrote: > On 22.02.2013 18:24, Riccardo Mottola wrote: > >> Fred Kiefer wrote: >> >>> On 22.02.2013 14:15, Riccardo Mottola wrote: >>> >>>> when I start Gorm and close it, no problem. When I start it and open a >>>> copuple of gorm files, everything file. If I open MDIndexer.m (of >>>> >>> >>> Did you mean the MDIndexer.gorm file? >>> >> yes, sorry. >> >> >>> GWorkspace's Preferences, the one we are investigating about blur) Gorm >>>> crashes on exist with the following segfault: >>>> >>>> 0xbb17ef1c in objc_msg_lookup () from /usr/lib/libobjc.so.3 >>>> (gdb) bt >>>> #0 0xbb17ef1c in objc_msg_lookup () from /usr/lib/libobjc.so.3 >>>> #1 0xbb89fab3 in -[NSWindow resignKeyWindow] (self=0xba944e14, >>>> _cmd=0xbb9c6c50) at NSWindow.m:1880 >>>> #2 0xbb6fdb54 in -[NSApplication deactivate] (self=0xba7371b4, >>>> _cmd=0xba6f7c28) at NSApplication.m:1361 >>>> #3 0xba6b8359 in -[XGServer(EventOps) processEvent:] (self=Cannot >>>> access memory at address 0xe000c >>>> ) >>>> at XGServerEvent.m:1152 >>>> #4 0xba6b321c in -[XGServer(EventOps) >>>> receivedEvent:type:extra:**forMode:] ( >>>> self=0xba8201c4, _cmd=0xbb633b28, data=0x7, type=ET_RDESC, >>>> extra=0x7, >>>> mode=0xba9ca144) at XGServerEvent.m:310 >>>> #5 0xbb4550d3 in -[GSRunLoopCtxt pollUntil:within:] (self=0xba72ba64, >>>> _cmd=0xbb5ef628, milliseconds=0, contexts=0xba9e9d84) >>>> at GSRunLoopCtxt.m:494 >>>> #6 0xbb385318 in -[NSRunLoop acceptInputForMode:beforeDate:**] ( >>>> self=0xba9e9d24, _cmd=0xbb5ef648, mode=0xba9ca144, >>>> limit_date=<optimized out>) at NSRunLoop.m:1206 >>>> <snip> >>>> >>> >>> I was able to reproduce a segmentation fault once. Next I tried in >>> gdb, but could not reproduces it and since then I fail to get it even >>> without gdb. I will fire up valgrind and see if that finds any anomaly. >>> From you back trace it looks like the issue involves notifications and >>> events, this could be very timing sensitive. >>> >>> The error itself seems to come from an invalid first responder in the >>> window. But which window? Could you try to print out some information >>> on the window? >>> >> Here it looks very consistent. The window on #1, shows this: >> >> <GormNSWindow: 0xba944f24>Number: 31 Title: Window >> Thus it looks to me that it is one of the Gorm windows (given the class >> name, but also the Title). However all the document windows are caled >> Window... I suppose it is the window with the tabview, because that one >> is key. >> > > I had to try about twenty times, but finally I was able to reproduce the > error in gdb. I am able to confirm that it is the window with the tabview > and that it is the _firstResponder that is causing the trouble: > > (gdb) p self->_firstResponder > $2 = (struct objc_object *) 0xf6b458 > (gdb) p *(self->_firstResponder) > $3 = {class_pointer = 0xdeadface} > > The address of the first responder does not match any of the current > subviews of the window. Most likely it is an editor that gets only added or > the initial first responder that point so some obsolete object. > > The simplest way to find out is to run Gorm with Zombies turned on and see > which class gets that call. As I need too long to reproduce the issue, it > would be best if your did those checks. > After that we will know whether the issue is in Gorm or in gui code and > maybe we even have an idea on how to fix it. > > > > > ______________________________**_________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/**listinfo/discuss-gnustep<https://lists.gnu.org/mailman/listinfo/discuss-gnustep> > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
