For the VM test I used the ones on the webpage (I do believe they're up to date), same ones I used on my machine after running into this problen in the previous version. That would be:
- make 2.6.6 - base 1.24.6 - gui 0.24.0 - back 0.24.0 - Gorm 1.2.18 On Sat, Jan 4, 2014 at 10:47 AM, Gregory Casamento <greg.casame...@gmail.com > wrote: > Please make sure you install a recent version of Gorm and GNUstep. I'm not > certain which version of base and GUI you're using. > > GC > > > On Saturday, January 4, 2014, Jamie Ramone wrote: > >> >> >> >> On Sat, Jan 4, 2014 at 7:59 AM, Fred Kiefer <fredkie...@gmx.de> wrote: >> >>> >>> Am 04.01.2014 um 00:17 schrieb Jamie Ramone <sancom...@gmail.com>: >>> >>> 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:] >> (self=self@entry=0xb4aa70, >> >> _cmd=_cmd@entry=0x7ffff75f0fb0 <_OBJC_SELECTOR_TABLE+7952>, >> anImage=anImage@entry=0x8866a0, screenLocation=..., >> initialOffset=..., event=event@entry=0xab2760, >> pboard=pboard@entry=0x10d12d0, >> sourceObject=sourceObject@entry=0xd536c0, >> slideFlag=slideFlag@entry=1 '\001') at XGDragView.m:228 >> #4 0x00007ffff71bfc36 in -[NSWindow >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xad8630, >> >> _cmd=_cmd@entry=0x7ffff75e6730 <_OBJC_SELECTOR_TABLE+5168>, >> anImage=anImage@entry=0x8866a0, baseLocation=..., >> initialOffset=..., event=event@entry=0xab2760, >> pboard=pboard@entry=0x10d12d0, >> sourceObject=sourceObject@entry=0xd536c0, >> slideFlag=slideFlag@entry=1 '\001') at NSWindow.m:4674 >> #5 0x00007ffff71a9464 in -[NSView >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xd536c0, >> >> _cmd=_cmd@entry=0x7ffff7da5ff0 <_OBJC_SELECTOR_TABLE+3120>, >> anImage=0x8866a0, viewLocation=..., initialOffset=..., >> event=event@entry=0xab2760, pboard=pboard@entry=0x10d12d0, >> sourceObject=sourceObject@entry=0xd536c0, >> slideFlag=slideFlag@entry=1 '\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 <sancom...@gmail.com> 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 <r...@gnu.org> 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 >> >> >> > > -- > 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 >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
