No idea about the NSWindow.m not found. I am running it on the machine it was compiled for. I did delete the sources afterward, but doesn't the code info get included with -g? If necessary, I can unpack the sources where I did the build last time. Would that help in the bug hunt? Just let me know.
Here's the ldd output: jamie@MyPC:~$ ldd /SystemApps/Gorm.app/Gorm linux-vdso.so.1 => (0x00007fff0cfff000) libGormCore.so.1 => /SystemLibrary/Libraries/libGormCore.so.1 (0x00007fd04788e000) libGorm.so.1 => /SystemLibrary/Libraries/libGorm.so.1 (0x00007fd04767e000) libGormPrefs.so.1 => /SystemLibrary/Libraries/libGormPrefs.so.1 (0x00007fd047465000) libgnustep-gui.so.0.24 => /SystemLibrary/Libraries/libgnustep-gui.so.0.24 (0x00007fd046c46000) libgnustep-base.so.1.24 => /SystemLibrary/Libraries/libgnustep-base.so.1.24 (0x00007fd04649b000) libobjc.so.3 => /usr/lib/x86_64-linux-gnu/libobjc.so.3 (0x00007fd04625f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd046049000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd045c89000) libGormObjCHeaderParser.so.1 => /SystemLibrary/Libraries/libGormObjCHeaderParser.so.1 (0x00007fd045a7b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd04585e000) libicuuc.so.48 => /usr/lib/libicuuc.so.48 (0x00007fd0454f4000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fd0452cb000) libgif.so.4 => /usr/lib/x86_64-linux-gnu/libgif.so.4 (0x00007fd0450c2000) libtiff.so.4 => /usr/lib/x86_64-linux-gnu/libtiff.so.4 (0x00007fd044e5e000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fd044c0d000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd044911000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007fd044655000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007fd0443d6000) libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007fd04419a000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007fd043e3e000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fd043c35000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd043a31000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd04381a000) libicui18n.so.48 => /usr/lib/libicui18n.so.48 (0x00007fd043451000) /lib64/ld-linux-x86-64.so.2 (0x00007fd047bf5000) libicudata.so.48 => /usr/lib/libicudata.so.48 (0x00007fd0420e1000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd041de0000) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007fd041bcf000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fd0419bc000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fd0417b8000) On Mon, Dec 30, 2013 at 1:55 PM, Fred Kiefer <fredkie...@gmx.de> wrote: > I asked for it, I got it and now it doesn't help me :-( > > Thank you for the stack trace. But now I am completely clueless. > Do you have an idea why the message "NSWindow.m: No such file or > directory." shows up? I would expect that you are running Gorm on the > same machine that you did compile GNUstep. If this is the case gdb > should be able to find the source file, as long as you did not strip > that information from the library. But you wrote that you did not > request any optimization. > > One last thing, could you please run ldd against your Gorm executable > and report back the result? Just to make sure that the correct GNUstep > library files get used. > > Looking at the code in NSWindow sendEvent: I see no way how self could > ever become nil. > > Fred > > On 30.12.2013 00:32, Jamie Ramone wrote: > > OK, here it is: > > > > (gdb) file /SystemApps/Gorm.app/Gorm > > Reading symbols from /SystemApps/Gorm.app/Gorm...done. > > (gdb) r > > Starting program: /SystemApps/Gorm.app/Gorm > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > > Program received signal SIGSEGV, Segmentation fault. > > -[NSWindow sendEvent:] (self=0x0, _cmd=<optimized out>, > theEvent=0xe121e0) > > at NSWindow.m:4414 > > 4414 NSWindow.m: No such file or directory. > > (gdb) bt > > #0 -[NSWindow sendEvent:] (self=0x0, _cmd=<optimized out>, > > theEvent=0xe121e0) > > at NSWindow.m:4414 > > #1 0x00007ffff71ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] > ( > > self=0xc55d00, _cmd=<optimized out>, theEvent=0x1061780, > slidePoint=...) > > at GSDragView.m:720 > > #2 0x00007ffff71ed20e in -[GSDragView > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > > _cmd=<optimized out>, anImage=0x9dc150, > > screenLocation=..., initialOffset=..., event=0x11073a0, > > pboard=<optimized out>, sourceObject=0xf2e5f0, slideFlag=1 '\001') > > at GSDragView.m:290 > > #3 0x00007ffff045e344 in -[XGDragView > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > > _cmd=<optimized out>, anImage=0x9dc150, > > screenLocation=..., initialOffset=..., event=0x11073a0, > > pboard=0x9d9470, > > sourceObject=0xf2e5f0, slideFlag=1 '\001') at XGDragView.m:228 > > #4 0x00007ffff71bebda in -[NSWindow > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb140b0, > > _cmd=<optimized out>, anImage=0x9dc150, > > baseLocation=..., initialOffset=..., event=0x11073a0, > > pboard=<optimized out>, sourceObject=<optimized out>, slideFlag=1 > > '\001') > > at NSWindow.m:4674 > > #5 0x00007ffff71a8c08 in -[NSView > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xf2e5f0, > > _cmd=<optimized out>, anImage=0x9dc150, > > ---Type <return> to continue, or q <return> to quit--- > > viewLocation=..., initialOffset=..., event=0x11073a0, > > pboard=<optimized out>, sourceObject=<optimized out>, slideFlag=1 > > '\001') > > at NSView.m:3860 > > #6 0x00007ffff7b2983c in -[GormObjectEditor mouseDown:] (self=0xf2e5f0, > > _cmd=<optimized out>, theEvent=0x11073a0) at GormObjectEditor.m:481 > > #7 0x00007ffff71ca953 in -[NSWindow sendEvent:] (self=0xb140b0, > > _cmd=<optimized out>, theEvent=0x11073a0) at NSWindow.m:3896 > > #8 0x00007ffff70343e3 in -[NSApplication run] (self=0x8c8450, > > _cmd=<optimized out>) at NSApplication.m:1562 > > #9 0x00007ffff70130d5 in NSApplicationMain (argc=<optimized out>, > > argv=<optimized out>) at Functions.m:91 > > #10 0x00007ffff5eab76d in __libc_start_main () > > from /lib/x86_64-linux-gnu/libc.so.6 > > #11 0x0000000000401965 in _start () > > (gdb) > > > > > > > > On Sun, Dec 29, 2013 at 6:50 PM, Fred Kiefer <fredkie...@gmx.de> wrote: > > > >> Yes! That was what I was asking for. > >> > >> Thank you, > >> Fred > >> > >> On 29.12.2013 22:28, Jamie Ramone wrote: > >>> I'm not sure how much more details you need. I stated that dragging a > >>> connection to any of the objects in the document window (i.e. the main > >>> project window) caused a segfault. I later discovered that dragging > from > >>> these objects toward any other one, outside that window, worked OK. And > >> it > >>> seems to be present in the current version of Gorm and updating the > >> GNUstep > >>> libs didn't alleviate the problem, which says to me that it's > >>> Gorm-specific. Oh and the GDB backtrace is from the old code. Would it > >> help > >>> to make another one with the new code? If so just let me know and I'll > >>> produce one. > >>> > >>> > >>> On Sun, Dec 29, 2013 at 6:20 PM, Fred Kiefer <fredkie...@gmx.de> > wrote: > >>> > >>>> On 29.12.2013 21:58, Gregory Casamento wrote: > >>>>> Between windows or between applications. I believe you’re hitting > >>>>> the same bug Fred may be hitting, I’m working on a potential fix > >>>>> now. > >>>> > >>>> You might be wrong here. German's bug, that I investigated, was Gorm > >>>> specific. If you advice Jamie to drag between another application and > >>>> GWorkspace it may never trigger the same bug. It might trigger a > similar > >>>> bug in GWorkspace if it has similar code to Gorm, but how likely is > >> that? > >>>> > >>>> And I wasn't able to reproduce Jamie's bug with Gorm. But then he > never > >>>> gave enough details to be sure. > >>>> > >>>> As you may remember German's bug did not include a segmentation fault, > >>>> which is the symptom Jamie is getting. What I would like to see is a > >>>> stack trace from Jamie with the current GNUstep code. With his old > one I > >>>> was never sure whether I was looking at the same line of code. For me > >>>> NSWindow.m:4288 is in the middle of the GSPerformVoidDragSelector > macro, > >>>> which isn't very likely. > >>>> > >>>> I really would like to establish the facts before coming to > conclusions > >>>> about the nature of the bug. > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev