gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serious GORM bug


From: Jamie Ramone
Subject: Re: Serious GORM bug
Date: Mon, 30 Dec 2013 15:30:11 -0200

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:

address@hidden:~$ 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]