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
