Re: Serious GORM bug

GC

On Saturday, January 4, 2014, Jamie Ramone wrote:

On Sat, Jan 4, 2014 at 7:59 AM, Fred Kiefer <address@hidden> wrote:

Am 04.01.2014 um 00:17 schrieb Jamie Ramone <address@hidden>:

Well $hit! I ran on a VM with Ubuntu 13.10...same problem:

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".
2014-01-03 20:09:11.042 Gorm[6849] QueryTree window is 25186477 (root 373 cwin root 373)
2014-01-03 20:09:11.102 Gorm[6849] QueryTree window is 25186476 (root 373 cwin root 373)
2014-01-03 20:09:11.573 Gorm[6849] QueryTree window is 25186511 (root 373 cwin root 373)
2014-01-03 20:09:11.574 Gorm[6849] QueryTree window is 25186510 (root 373 cwin root 373)

Could you please explain where these messages come from? Are you using unaltered GNUstep code, or if you have changes would you mind telling us about them? This looks a bit like the debugging code I used in the backend to track down the other Gorm bug, which actually turned out to be a Gorm bug.

If you want to see more information on what is happening inside of the running Gorm application start it with parameters such as "--GNU-Debug=dflt", "--GNU-Debug=NSEvent" or "--GNU-Debug=NSDragging" (typed from memory, better check the correct names in the source code).

To my knowledge, it's unaltered. I didn't touch any line of Gorm's code, just downloaded and compiled it. OK, I'll try those.

Program received signal SIGSEGV, Segmentation fault.
-[NSWindow sendEvent:] (self=0x0, _cmd=<optimized out>, theEvent=0x1080810) at NSWindow.m:4409
4409    NSWindow.m: No such file or directory.

Again you seem to have deleted the source code. Why do you keep on doing this.

Aw crap, it's still popping up! Actually, I didn't. I left the GNUstep code as it was after installing it in the VM, which makes this line even more mysterious.

(gdb) bt
#0 -[NSWindow sendEvent:] (self=0x0, _cmd=<optimized out>, theEvent=0x1080810) at NSWindow.m:4409

As I already wrote, nil as self is only possible if something in the method sets this explicitly or due to a compiler bug, which is not very likely. Which complier and runtime are you using here?

The GNU runtime. I checked that line, there's a macro there and seems harmless. if self's nil at that point it's being changed somewhere in that method, but before the macro is expanded. I'll have to keep digging.

#1 0x00007ffff71ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] (self=0xb4aa70, _cmd=<optimized out>, theEvent=0x1052960,
    slidePoint=...) at GSDragView.m:720
#2 0x00007ffff71e88e3 in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70,
    _cmd=<optimized out>, anImage=0x8866a0, screenLocation=..., initialOffset=..., event=0xab2760, pboard=<optimized out>,
    sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290
#3 0x00007ffff2208769 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (address@hidden,
    address@hidden <_OBJC_SELECTOR_TABLE+7952>, address@hidden, screenLocation=...,
    initialOffset=..., address@hidden, address@hidden, address@hidden,
    address@hidden '\001') at XGDragView.m:228
#4 0x00007ffff71bfc36 in -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] (address@hidden,
    address@hidden <_OBJC_SELECTOR_TABLE+5168>, address@hidden, baseLocation=...,
    initialOffset=..., address@hidden, address@hidden, address@hidden,
    address@hidden '\001') at NSWindow.m:4674
#5 0x00007ffff71a9464 in -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] (address@hidden,
    address@hidden <_OBJC_SELECTOR_TABLE+3120>, anImage=0x8866a0, viewLocation=..., initialOffset=...,
    address@hidden, address@hidden, address@hidden,
    address@hidden '\001') at NSView.m:3860
#6 0x00007ffff7b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, _cmd=<optimized out>, theEvent=0xab2760)
    at GormObjectEditor.m:481
#7 0x00007ffff71c93d0 in -[NSWindow sendEvent:] (self=0xad8630, _cmd=<optimized out>, theEvent=0xab2760) at NSWindow.m:3896
#8 0x00007ffff704c6f3 in -[NSApplication run] (self=0x87e2f0, _cmd=<optimized out>) at NSApplication.m:1562
#9 0x00007ffff702cfe5 in NSApplicationMain (argc=<optimized out>, argv=<optimized out>) at Functions.m:91
#10 0x00007ffff5ed5de5 in __libc_start_main (main=0x4019c0 <main>, argc=1, ubp_av=0x7fffffffdc78, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdc68) at libc-start.c:260
#11 0x0000000000401a05 in _start ()

At least it's now showing the NSWindow.m info. I'll see if I can dig up anything else.

On Fri, Jan 3, 2014 at 1:36 AM, Jamie Ramone <address@hidden> wrote:

So, I'll have to wait for 14 to come out then. I can live with that I guess. In any case I'll give it a go on a VM with 13.10 (wish me luck).As for GWorkspace I never use it's desktop. It interferes with everything else. And no, it doesn't work on both as I stated earlier.

On Wed, Jan 1, 2014 at 4:38 PM, Riccardo Mottola <address@hidden> wrote:

Jamie Ramone wrote:

OK, got it, I'll try that now (between windows, not sure how to do the
"between applications" yet). Just a heads up: I did eventually, er, "erase"
the folders by selecting them and dragging them to the Recycler's
pseudo-appicon and it worked without a hitch. Since Recycler.app is another
app I guess that would count.

Depends if you are using the recycler in the desktop+dock, or if you are using the separate recycler app. They should, of course, work both.

Riccardo

_______________________________________________
Gnustep-dev mailing list

From:	Gregory Casamento
Subject:	Re: Serious GORM bug
Date:	Sat, 4 Jan 2014 08:47:46 -0500