Re: Serious GORM bug
Hey Jamie, Could you give us some information about your environment? Greg On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote: > Hi there steppers! OK, here's the deal: I'v been playing around with GORM > making a demo of an extended scroll view (a subclass of NSScrollView with > some practical general purpose extensions) and I came across a > connection-related bug in GORM. Apparently, (manually) connecting any object > to any object in the document window makes GORM barf with a segfault. > Connecting objects inside of a window, panel, or menu (i.e. belonging to the > document but NOT dropping the conection icon in the document window but > rather in one of there) seems to work fine, though I haven't tested this > extensively. I believe I have the most recent version and haven't seen any > notice of new versions since building this one. The specific version is > 1.2.17. And as far as the GNUstep libs I'm using the previous version and > GORM is linked against them. This bug is a total show stopper for me and, if > anyone else is affected, I believe it would be for them as well. Greg, could > you please look into this? Thanx! > > -- > ¡Besos, abrazos, confetti y aplausos! > Jamie "El Vikingo" Ramone ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon (6 processors), I recently recompiled GNUstep from scratch because the entire system died (not sure what caused it but the UI never came back so I had to reinstall the system). Also, I'm using WindowMaker as unity has pretty much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a lepper in the middle ages, everyting is compiled by me here. GNUstep, GORM, Project Center, the whole sh'bang. Anything else you need to know? -- ¡Besos, abrazos, confetti y aplausos! Jamie "El Vikingo" Ramone On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento wrote: > Hey Jamie, > > Could you give us some information about your environment? > > Greg > > On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote: > > > Hi there steppers! OK, here's the deal: I'v been playing around with > GORM making a demo of an extended scroll view (a subclass of NSScrollView > with some practical general purpose extensions) and I came across a > connection-related bug in GORM. Apparently, (manually) connecting any > object to any object in the document window makes GORM barf with a > segfault. Connecting objects inside of a window, panel, or menu (i.e. > belonging to the document but NOT dropping the conection icon in the > document window but rather in one of there) seems to work fine, though I > haven't tested this extensively. I believe I have the most recent version > and haven't seen any notice of new versions since building this one. The > specific version is 1.2.17. And as far as the GNUstep libs I'm using the > previous version and GORM is linked against them. This bug is a total show > stopper for me and, if anyone else is affected, I believe it would be for > them as well. Greg, could you please look into this? Thanx! > > > > -- > > ¡Besos, abrazos, confetti y aplausos! > > Jamie "El Vikingo" Ramone > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
No, nothing more needed I'll check it out thanks. On Friday, December 27, 2013, Jamie Ramone wrote: > Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon (6 > processors), I recently recompiled GNUstep from scratch because the entire > system died (not sure what caused it but the UI never came back so I had to > reinstall the system). Also, I'm using WindowMaker as unity has pretty > much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a lepper > in the middle ages, everyting is compiled by me here. GNUstep, GORM, > Project Center, the whole sh'bang. Anything else you need to know? > > -- > ¡Besos, abrazos, confetti y aplausos! > Jamie "El Vikingo" Ramone > > On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento < > greg.casame...@gmail.com 'greg.casame...@gmail.com');>> wrote: > >> Hey Jamie, >> >> Could you give us some information about your environment? >> >> Greg >> >> On Dec 27, 2013, at 4:11 PM, Jamie Ramone >> > >> wrote: >> >> > Hi there steppers! OK, here's the deal: I'v been playing around with >> GORM making a demo of an extended scroll view (a subclass of NSScrollView >> with some practical general purpose extensions) and I came across a >> connection-related bug in GORM. Apparently, (manually) connecting any >> object to any object in the document window makes GORM barf with a >> segfault. Connecting objects inside of a window, panel, or menu (i.e. >> belonging to the document but NOT dropping the conection icon in the >> document window but rather in one of there) seems to work fine, though I >> haven't tested this extensively. I believe I have the most recent version >> and haven't seen any notice of new versions since building this one. The >> specific version is 1.2.17. And as far as the GNUstep libs I'm using the >> previous version and GORM is linked against them. This bug is a total show >> stopper for me and, if anyone else is affected, I believe it would be for >> them as well. Greg, could you please look into this? Thanx! >> > >> > -- >> > ¡Besos, abrazos, confetti y aplausos! >> > Jamie "El Vikingo" Ramone >> >> > -- 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
Re: Serious GORM bug
Thanx man! Oh just a plus: I don't use the new language runtime (libobjc 2). Also, I found that connecting FROM an object in the document window TO a control on a window seems to work fine. On Sat, Dec 28, 2013 at 10:19 AM, Gregory Casamento < greg.casame...@gmail.com> wrote: > No, nothing more needed I'll check it out thanks. > > > On Friday, December 27, 2013, Jamie Ramone wrote: > >> Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon (6 >> processors), I recently recompiled GNUstep from scratch because the entire >> system died (not sure what caused it but the UI never came back so I had to >> reinstall the system). Also, I'm using WindowMaker as unity has pretty >> much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a lepper >> in the middle ages, everyting is compiled by me here. GNUstep, GORM, >> Project Center, the whole sh'bang. Anything else you need to know? >> >> -- >> ¡Besos, abrazos, confetti y aplausos! >> Jamie "El Vikingo" Ramone >> >> On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Hey Jamie, >>> >>> Could you give us some information about your environment? >>> >>> Greg >>> >>> On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote: >>> >>> > Hi there steppers! OK, here's the deal: I'v been playing around with >>> GORM making a demo of an extended scroll view (a subclass of NSScrollView >>> with some practical general purpose extensions) and I came across a >>> connection-related bug in GORM. Apparently, (manually) connecting any >>> object to any object in the document window makes GORM barf with a >>> segfault. Connecting objects inside of a window, panel, or menu (i.e. >>> belonging to the document but NOT dropping the conection icon in the >>> document window but rather in one of there) seems to work fine, though I >>> haven't tested this extensively. I believe I have the most recent version >>> and haven't seen any notice of new versions since building this one. The >>> specific version is 1.2.17. And as far as the GNUstep libs I'm using the >>> previous version and GORM is linked against them. This bug is a total show >>> stopper for me and, if anyone else is affected, I believe it would be for >>> them as well. Greg, could you please look into this? Thanx! >>> > >>> > -- >>> > ¡Besos, abrazos, confetti y aplausos! >>> > Jamie "El Vikingo" Ramone >>> >>> >> > > -- > 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
Re: Serious GORM bug
Gorm shouldn't require anything in the new runtime. I've tried creating connections between several objects in the document window. I can't seem to reproduce this issue. Could you run in GDB and provide me a backtrace? I will continue to test things here to see if I can reproduce the issue. Greg On Sat, Dec 28, 2013 at 1:40 PM, Jamie Ramone wrote: > Thanx man! Oh just a plus: I don't use the new language runtime (libobjc > 2). Also, I found that connecting FROM an object in the document window TO > a control on a window seems to work fine. > > > On Sat, Dec 28, 2013 at 10:19 AM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > >> No, nothing more needed I'll check it out thanks. >> >> >> On Friday, December 27, 2013, Jamie Ramone wrote: >> >>> Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon >>> (6 processors), I recently recompiled GNUstep from scratch because the >>> entire system died (not sure what caused it but the UI never came back so I >>> had to reinstall the system). Also, I'm using WindowMaker as unity has >>> pretty much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a >>> lepper in the middle ages, everyting is compiled by me here. GNUstep, GORM, >>> Project Center, the whole sh'bang. Anything else you need to know? >>> >>> -- >>> ¡Besos, abrazos, confetti y aplausos! >>> Jamie "El Vikingo" Ramone >>> >>> On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> Hey Jamie, Could you give us some information about your environment? Greg On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote: > Hi there steppers! OK, here's the deal: I'v been playing around with GORM making a demo of an extended scroll view (a subclass of NSScrollView with some practical general purpose extensions) and I came across a connection-related bug in GORM. Apparently, (manually) connecting any object to any object in the document window makes GORM barf with a segfault. Connecting objects inside of a window, panel, or menu (i.e. belonging to the document but NOT dropping the conection icon in the document window but rather in one of there) seems to work fine, though I haven't tested this extensively. I believe I have the most recent version and haven't seen any notice of new versions since building this one. The specific version is 1.2.17. And as far as the GNUstep libs I'm using the previous version and GORM is linked against them. This bug is a total show stopper for me and, if anyone else is affected, I believe it would be for them as well. Greg, could you please look into this? Thanx! > > -- > ¡Besos, abrazos, confetti y aplausos! > Jamie "El Vikingo" Ramone >>> >> >> -- >> 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 >> > > -- 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
Re: Serious GORM bug
K, here's what I got:
(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".
2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
-[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
dictionary {}
Program received signal SIGSEGV, Segmentation fault.
-[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
at NSWindow.m:4288
4288NSWindow.m: No such file or directory.
(gdb) bt
#0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
theEvent=0xb4bd20)
at NSWindow.m:4288
#1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
self=0xc22440, _cmd=, theEvent=0xd52c80, slidePoint=...)
at GSDragView.m:720
#2 0x771e in -[GSDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
_cmd=, anImage=0x7b0fe0,
screenLocation=..., initialOffset=..., event=0xda00a0,
pboard=, sourceObject=0xcb8bc0, slideFlag=1 '\001')
at GSDragView.m:290
#3 0x7049b254 in -[XGDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
_cmd=, anImage=0x7b0fe0,
screenLocation=..., initialOffset=..., event=0xda00a0, pboard=0xd87800,
sourceObject=0xcb8bc0, slideFlag=1 '\001') at XGDragView.m:228
#4 0x771d361a in -[NSWindow
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcab1a0,
_cmd=, anImage=0x7b0fe0,
baseLocation=..., initialOffset=..., event=0xda00a0,
pboard=, sourceObject=, slideFlag=1
'\001')
at NSWindow.m:4548
#5 0x771bd7a8 in -[NSView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcb8bc0,
_cmd=, anImage=0x7b0fe0,
viewLocation=..., initialOffset=..., event=0xda00a0,
pboard=, sourceObject=, slideFlag=1
'\001')
---Type to continue, or q to quit---
at NSView.m:3858
#6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xcb8bc0,
_cmd=, theEvent=0xda00a0) at GormObjectEditor.m:481
#7 0x771df003 in -[NSWindow sendEvent:] (self=0xcab1a0,
_cmd=, theEvent=0xda00a0) at NSWindow.m:3790
#8 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
_cmd=) at NSApplication.m:1562
#9 0x77032945 in NSApplicationMain (argc=,
argv=) at Functions.m:91
#10 0x75ee676d in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#11 0x00401965 in _start ()
(gdb)
For this I started out with an empty document (Document>New Module>New
Empty), added a window and attempted to make a connection from the window
to NSOwner, within the document window. Next I'll try between a control and
NSOwner.
On Sat, Dec 28, 2013 at 4:52 PM, Gregory Casamento wrote:
> Gorm shouldn't require anything in the new runtime. I've tried creating
> connections between several objects in the document window. I can't seem
> to reproduce this issue.
>
> Could you run in GDB and provide me a backtrace? I will continue to test
> things here to see if I can reproduce the issue.
>
> Greg
>
>
> On Sat, Dec 28, 2013 at 1:40 PM, Jamie Ramone wrote:
>
>> Thanx man! Oh just a plus: I don't use the new language runtime (libobjc
>> 2). Also, I found that connecting FROM an object in the document window TO
>> a control on a window seems to work fine.
>>
>>
>> On Sat, Dec 28, 2013 at 10:19 AM, Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>> No, nothing more needed I'll check it out thanks.
>>>
>>>
>>> On Friday, December 27, 2013, Jamie Ramone wrote:
>>>
Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon
(6 processors), I recently recompiled GNUstep from scratch because the
entire system died (not sure what caused it but the UI never came back so I
had to reinstall the system). Also, I'm using WindowMaker as unity has
pretty much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a
lepper in the middle ages, everyting is compiled by me here. GNUstep, GORM,
Project Center, the whole sh'bang. Anything else you need to know?
--
¡Besos, abrazos, confetti y aplausos!
Jamie "El Vikingo" Ramone
On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento <
greg.casame...@gmail.com> wrote:
> Hey Jamie,
>
> Could you give us some information about your environment?
>
> Greg
>
> On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote:
>
> > Hi there steppers! OK, here's the deal: I'v been playing around with
> GORM making a demo of an extended scroll view (a subclass of NSScrollView
> with some practical general purpose extensions) and I came across a
> connection-related bug in GORM. Apparently, (manually) connecting any
> object to any object in the document window makes GORM barf with a
> segfault. Connecting objects inside of a window, panel, or menu (i.
Re: Serious GORM bug
Here's the 2nd test:
(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=, theEvent=0x10e59a0)
at NSWindow.m:4288
4288NSWindow.m: No such file or directory.
(gdb) bt
#0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
theEvent=0x10e59a0)
at NSWindow.m:4288
#1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
self=0xad5c80, _cmd=, theEvent=0x1110160, slidePoint=...)
at GSDragView.m:720
#2 0x771e in -[GSDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
_cmd=, anImage=0x7b2300,
screenLocation=..., initialOffset=..., event=0x8c7470,
pboard=, sourceObject=0xd35030, slideFlag=1 '\001')
at GSDragView.m:290
#3 0x7049b254 in -[XGDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
_cmd=, anImage=0x7b2300,
screenLocation=..., initialOffset=..., event=0x8c7470, pboard=0xc49240,
sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228
#4 0x771d361a in -[NSWindow
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900,
_cmd=, anImage=0x7b2300,
baseLocation=..., initialOffset=..., event=0x8c7470,
pboard=, sourceObject=, slideFlag=1
'\001')
at NSWindow.m:4548
#5 0x771bd7a8 in -[NSView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030,
_cmd=, anImage=0x7b2300,
viewLocation=..., initialOffset=..., event=0x8c7470,
pboard=, sourceObject=, slideFlag=1
'\001')
at NSView.m:3858
#6 0x77b3f569 in -[GormViewEditor
startConnectingObject:withEvent:] (
self=0xd35030, _cmd=, anObject=,
theEvent=0x8c7470) at GormViewEditor.m:1203
#7 0x77b368b1 in -[GormScrollViewEditor mouseDown:]
(self=0xd35030,
_cmd=, theEvent=0x8c7470) at GormScrollViewEditor.m:123
#8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900,
_cmd=, theEvent=0x8c7470) at NSWindow.m:3790
#9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
_cmd=) at NSApplication.m:1562
#10 0x77032945 in NSApplicationMain (argc=,
argv=) at Functions.m:91
#11 0x75ee676d in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00401965 in _start ()
(gdb)
Same as before, but with a tableview in a new window, and making the
connection from it to NSOwner.
On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone wrote:
> K, here's what I got:
>
> (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".
> 2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
> -[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
> dictionary {}
>
> Program received signal SIGSEGV, Segmentation fault.
> -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
> at NSWindow.m:4288
> 4288NSWindow.m: No such file or directory.
> (gdb) bt
> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
> theEvent=0xb4bd20)
> at NSWindow.m:4288
> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
> self=0xc22440, _cmd=, theEvent=0xd52c80, slidePoint=...)
> at GSDragView.m:720
> #2 0x771e in -[GSDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
> _cmd=, anImage=0x7b0fe0,
> screenLocation=..., initialOffset=..., event=0xda00a0,
> pboard=, sourceObject=0xcb8bc0, slideFlag=1 '\001')
> at GSDragView.m:290
> #3 0x7049b254 in -[XGDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
> _cmd=, anImage=0x7b0fe0,
> screenLocation=..., initialOffset=..., event=0xda00a0,
> pboard=0xd87800,
> sourceObject=0xcb8bc0, slideFlag=1 '\001') at XGDragView.m:228
> #4 0x771d361a in -[NSWindow
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcab1a0,
> _cmd=, anImage=0x7b0fe0,
> baseLocation=..., initialOffset=..., event=0xda00a0,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> at NSWindow.m:4548
> #5 0x771bd7a8 in -[NSView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcb8bc0,
> _cmd=, anImage=0x7b0fe0,
> viewLocation=..., initialOffset=..., event=0xda00a0,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> ---Type to continue, or q to quit---
> at NSView.m:3858
> #6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xcb8bc0,
> _cmd=, theEvent=0xda00a0) at GormObjectEditor.m:481
> #7 0x771df003 in -[NSWindow sendEvent:] (self=0xcab1a0,
> _cmd=, theEvent=0
Re: Serious GORM bug
What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent
method. While that doesn't seem right, nil is a valid receiver as far as
the runtime's concerned. So I'n still unsure of the cause of the segfault.
Let me know what you find Greg.
On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone wrote:
> Here's the 2nd test:
>
> (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=, theEvent=0x10e59a0)
>
> at NSWindow.m:4288
> 4288NSWindow.m: No such file or directory.
> (gdb) bt
> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
> theEvent=0x10e59a0)
>
> at NSWindow.m:4288
> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
> self=0xad5c80, _cmd=, theEvent=0x1110160,
> slidePoint=...)
> at GSDragView.m:720
> #2 0x771e in -[GSDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
> _cmd=, anImage=0x7b2300,
> screenLocation=..., initialOffset=..., event=0x8c7470,
> pboard=, sourceObject=0xd35030, slideFlag=1 '\001')
> at GSDragView.m:290
> #3 0x7049b254 in -[XGDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
> _cmd=, anImage=0x7b2300,
> screenLocation=..., initialOffset=..., event=0x8c7470,
> pboard=0xc49240,
> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228
> #4 0x771d361a in -[NSWindow
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900,
> _cmd=, anImage=0x7b2300,
> baseLocation=..., initialOffset=..., event=0x8c7470,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> at NSWindow.m:4548
> #5 0x771bd7a8 in -[NSView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030,
> _cmd=, anImage=0x7b2300,
> viewLocation=..., initialOffset=..., event=0x8c7470,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> at NSView.m:3858
> #6 0x77b3f569 in -[GormViewEditor
> startConnectingObject:withEvent:] (
> self=0xd35030, _cmd=, anObject=,
> theEvent=0x8c7470) at GormViewEditor.m:1203
> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:]
> (self=0xd35030,
> _cmd=, theEvent=0x8c7470) at GormScrollViewEditor.m:123
> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900,
> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790
> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
> _cmd=) at NSApplication.m:1562
> #10 0x77032945 in NSApplicationMain (argc=,
> argv=) at Functions.m:91
> #11 0x75ee676d in __libc_start_main ()
>from /lib/x86_64-linux-gnu/libc.so.6
> #12 0x00401965 in _start ()
> (gdb)
>
> Same as before, but with a tableview in a new window, and making the
> connection from it to NSOwner.
>
>
> On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone wrote:
>
>> K, here's what I got:
>>
>> (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".
>> 2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
>> -[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
>> dictionary {}
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
>> at NSWindow.m:4288
>> 4288NSWindow.m: No such file or directory.
>> (gdb) bt
>> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
>> theEvent=0xb4bd20)
>> at NSWindow.m:4288
>> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
>> self=0xc22440, _cmd=, theEvent=0xd52c80,
>> slidePoint=...)
>> at GSDragView.m:720
>> #2 0x771e in -[GSDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
>> _cmd=, anImage=0x7b0fe0,
>> screenLocation=..., initialOffset=..., event=0xda00a0,
>> pboard=, sourceObject=0xcb8bc0, slideFlag=1 '\001')
>> at GSDragView.m:290
>> #3 0x7049b254 in -[XGDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
>> _cmd=, anImage=0x7b0fe0,
>> screenLocation=..., initialOffset=..., event=0xda00a0,
>> pboard=0xd87800,
>> sourceObject=0xcb8bc0, slideFlag=1 '\001') at XGDragView.m:228
>> #4 0x771d361a in -[NSWindow
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcab1a0,
>> _cmd=, anImage=0x7b0fe0,
>> baseLocation=..., initialOffset=..., event=0xda00a0,
>> pboard=, sourceObject=, slideFlag=1
>> '\001')
>> at NSWindow.m:4548
>> #5 0x771bd7a8 in -[NSView
>>
Re: Serious GORM bug
I was not able to reproduce your problem on my system. Maybe more
detailed instructions would be helpful. What I noticed when looking at
your stack trace is that a lot of intermediate methods are left out
there. Which optimisation level are you using for your compiler when
compiling GNUstep gui?
You should also try to print out the event (po theEvent and p *theEvent)
and inspect the window given in the event. This should be the window the
event gets send to.
Could you please update your GNUstep installation to the latest release?
This makes it easier to compare the line numbers in the stack trace.
Fred
On 28.12.2013 22:30, Jamie Ramone wrote:
> What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent
> method. While that doesn't seem right, nil is a valid receiver as far as
> the runtime's concerned. So I'n still unsure of the cause of the segfault.
> Let me know what you find Greg.
>
>
> On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone wrote:
>
>> Here's the 2nd test:
>>
>> (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=, theEvent=0x10e59a0)
>>
>> at NSWindow.m:4288
>> 4288NSWindow.m: No such file or directory.
>> (gdb) bt
>> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
>> theEvent=0x10e59a0)
>>
>> at NSWindow.m:4288
>> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
>> self=0xad5c80, _cmd=, theEvent=0x1110160,
>> slidePoint=...)
>> at GSDragView.m:720
>> #2 0x771e in -[GSDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
>> _cmd=, anImage=0x7b2300,
>> screenLocation=..., initialOffset=..., event=0x8c7470,
>> pboard=, sourceObject=0xd35030, slideFlag=1 '\001')
>> at GSDragView.m:290
>> #3 0x7049b254 in -[XGDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
>> _cmd=, anImage=0x7b2300,
>> screenLocation=..., initialOffset=..., event=0x8c7470,
>> pboard=0xc49240,
>> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228
>> #4 0x771d361a in -[NSWindow
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900,
>> _cmd=, anImage=0x7b2300,
>> baseLocation=..., initialOffset=..., event=0x8c7470,
>> pboard=, sourceObject=, slideFlag=1
>> '\001')
>> at NSWindow.m:4548
>> #5 0x771bd7a8 in -[NSView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030,
>> _cmd=, anImage=0x7b2300,
>> viewLocation=..., initialOffset=..., event=0x8c7470,
>> pboard=, sourceObject=, slideFlag=1
>> '\001')
>> at NSView.m:3858
>> #6 0x77b3f569 in -[GormViewEditor
>> startConnectingObject:withEvent:] (
>> self=0xd35030, _cmd=, anObject=,
>> theEvent=0x8c7470) at GormViewEditor.m:1203
>> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:]
>> (self=0xd35030,
>> _cmd=, theEvent=0x8c7470) at GormScrollViewEditor.m:123
>> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900,
>> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790
>> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
>> _cmd=) at NSApplication.m:1562
>> #10 0x77032945 in NSApplicationMain (argc=,
>> argv=) at Functions.m:91
>> #11 0x75ee676d in __libc_start_main ()
>>from /lib/x86_64-linux-gnu/libc.so.6
>> #12 0x00401965 in _start ()
>> (gdb)
>>
>> Same as before, but with a tableview in a new window, and making the
>> connection from it to NSOwner.
>>
>>
>> On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone wrote:
>>
>>> K, here's what I got:
>>>
>>> (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".
>>> 2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
>>> -[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
>>> dictionary {}
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
>>> at NSWindow.m:4288
>>> 4288NSWindow.m: No such file or directory.
>>> (gdb) bt
>>> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
>>> theEvent=0xb4bd20)
>>> at NSWindow.m:4288
>>> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
>>> self=0xc22440, _cmd=, theEvent=0xd52c80,
>>> slidePoint=...)
>>> at GSDragView.m:720
>>> #2 0x771e in -[GSDragView
>>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
>>> _cmd=, anImage=0x7b0fe0,
Re: Serious GORM bug
Optimization??? I just use configure and the supplied makefile. Anyway, I'm gonna completely wipe out the current GNUstep installation and build it from scratch. I suspect some corruption crept in with that nasty system crash I had. I reinstalled GNUstep on top of the old installation that time. I'll first use the sources I already had and see if the bug goes away. regardless, I'll update after that. Stand by for updates. On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: > I was not able to reproduce your problem on my system. Maybe more > detailed instructions would be helpful. What I noticed when looking at > your stack trace is that a lot of intermediate methods are left out > there. Which optimisation level are you using for your compiler when > compiling GNUstep gui? > You should also try to print out the event (po theEvent and p *theEvent) > and inspect the window given in the event. This should be the window the > event gets send to. > > Could you please update your GNUstep installation to the latest release? > This makes it easier to compare the line numbers in the stack trace. > > Fred > > On 28.12.2013 22:30, Jamie Ramone wrote: > > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent > > method. While that doesn't seem right, nil is a valid receiver as far as > > the runtime's concerned. So I'n still unsure of the cause of the > segfault. > > Let me know what you find Greg. > > > > > > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone > wrote: > > > >> Here's the 2nd test: > >> > >> (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=, > theEvent=0x10e59a0) > >> > >> at NSWindow.m:4288 > >> 4288NSWindow.m: No such file or directory. > >> (gdb) bt > >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > >> theEvent=0x10e59a0) > >> > >> at NSWindow.m:4288 > >> #1 0x77201e8c in -[GSDragView(Private) > _handleDrag:slidePoint:] ( > >> self=0xad5c80, _cmd=, theEvent=0x1110160, > >> slidePoint=...) > >> at GSDragView.m:720 > >> #2 0x771e in -[GSDragView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, > >> _cmd=, anImage=0x7b2300, > >> screenLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') > >> at GSDragView.m:290 > >> #3 0x7049b254 in -[XGDragView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, > >> _cmd=, anImage=0x7b2300, > >> screenLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=0xc49240, > >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 > >> #4 0x771d361a in -[NSWindow > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, > >> _cmd=, anImage=0x7b2300, > >> baseLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=, slideFlag=1 > >> '\001') > >> at NSWindow.m:4548 > >> #5 0x771bd7a8 in -[NSView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, > >> _cmd=, anImage=0x7b2300, > >> viewLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=, slideFlag=1 > >> '\001') > >> at NSView.m:3858 > >> #6 0x77b3f569 in -[GormViewEditor > >> startConnectingObject:withEvent:] ( > >> self=0xd35030, _cmd=, anObject=, > >> theEvent=0x8c7470) at GormViewEditor.m:1203 > >> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:] > >> (self=0xd35030, > >> _cmd=, theEvent=0x8c7470) at > GormScrollViewEditor.m:123 > >> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900, > >> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790 > >> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0, > >> _cmd=) at NSApplication.m:1562 > >> #10 0x77032945 in NSApplicationMain (argc=, > >> argv=) at Functions.m:91 > >> #11 0x75ee676d in __libc_start_main () > >>from /lib/x86_64-linux-gnu/libc.so.6 > >> #12 0x00401965 in _start () > >> (gdb) > >> > >> Same as before, but with a tableview in a new window, and making the > >> connection from it to NSOwner. > >> > >> > >> On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone > wrote: > >> > >>> K, here's what I got: > >>> > >>> (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". > >>> 2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In > >>> -[GSMutableDictionary remo
Re: Serious GORM bug
OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try the most recent release. Wish me luck! :) On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: > Optimization??? I just use configure and the supplied makefile. Anyway, > I'm gonna completely wipe out the current GNUstep installation and build it > from scratch. I suspect some corruption crept in with that nasty system > crash I had. I reinstalled GNUstep on top of the old installation that > time. I'll first use the sources I already had and see if the bug goes > away. regardless, I'll update after that. Stand by for updates. > > > On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: > >> I was not able to reproduce your problem on my system. Maybe more >> detailed instructions would be helpful. What I noticed when looking at >> your stack trace is that a lot of intermediate methods are left out >> there. Which optimisation level are you using for your compiler when >> compiling GNUstep gui? >> You should also try to print out the event (po theEvent and p *theEvent) >> and inspect the window given in the event. This should be the window the >> event gets send to. >> >> Could you please update your GNUstep installation to the latest release? >> This makes it easier to compare the line numbers in the stack trace. >> >> Fred >> >> On 28.12.2013 22:30, Jamie Ramone wrote: >> > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent >> > method. While that doesn't seem right, nil is a valid receiver as far as >> > the runtime's concerned. So I'n still unsure of the cause of the >> segfault. >> > Let me know what you find Greg. >> > >> > >> > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone >> wrote: >> > >> >> Here's the 2nd test: >> >> >> >> (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=, >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> 4288NSWindow.m: No such file or directory. >> >> (gdb) bt >> >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >> >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> #1 0x77201e8c in -[GSDragView(Private) >> _handleDrag:slidePoint:] ( >> >> self=0xad5c80, _cmd=, theEvent=0x1110160, >> >> slidePoint=...) >> >> at GSDragView.m:720 >> >> #2 0x771e in -[GSDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') >> >> at GSDragView.m:290 >> >> #3 0x7049b254 in -[XGDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=0xc49240, >> >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 >> >> #4 0x771d361a in -[NSWindow >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, >> >> _cmd=, anImage=0x7b2300, >> >> baseLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=, slideFlag=1 >> >> '\001') >> >> at NSWindow.m:4548 >> >> #5 0x771bd7a8 in -[NSView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, >> >> _cmd=, anImage=0x7b2300, >> >> viewLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=, slideFlag=1 >> >> '\001') >> >> at NSView.m:3858 >> >> #6 0x77b3f569 in -[GormViewEditor >> >> startConnectingObject:withEvent:] ( >> >> self=0xd35030, _cmd=, anObject=, >> >> theEvent=0x8c7470) at GormViewEditor.m:1203 >> >> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:] >> >> (self=0xd35030, >> >> _cmd=, theEvent=0x8c7470) at >> GormScrollViewEditor.m:123 >> >> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900, >> >> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790 >> >> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0, >> >> _cmd=) at NSApplication.m:1562 >> >> #10 0x77032945 in NSApplicationMain (argc=, >> >> argv=) at Functions.m:91 >> >> #11 0x75ee676d in __libc_start_main () >> >>from /lib/x86_64-linux-gnu/libc.so.6 >> >> #12 0x00401965 in _start () >> >> (gdb) >> >> >> >> Same as before, but with a tableview in a new window, and making the >> >> connection from it to NSOwner. >> >> >> >> >> >> On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone >> wrote: >> >> >> >>> K, here's what I got: >> >>> >> >>> (gdb) file /SystemApps/Gorm.app/Gorm >> >>> Reading symbols from /SystemApps/Gorm.app/Gorm...done. >> >
Re: Serious GORM bug
When wiping GNUstep off your system (before a reinstall, of course!), don't forget /etc/GNUstep.conf -- or something like that. On Sun, Dec 29, 2013 at 12:37 AM, Jamie Ramone wrote: > OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try > the most recent release. Wish me luck! :) > > > On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: > >> Optimization??? I just use configure and the supplied makefile. Anyway, >> I'm gonna completely wipe out the current GNUstep installation and build it >> from scratch. I suspect some corruption crept in with that nasty system >> crash I had. I reinstalled GNUstep on top of the old installation that >> time. I'll first use the sources I already had and see if the bug goes >> away. regardless, I'll update after that. Stand by for updates. >> >> >> On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: >> >>> I was not able to reproduce your problem on my system. Maybe more >>> detailed instructions would be helpful. What I noticed when looking at >>> your stack trace is that a lot of intermediate methods are left out >>> there. Which optimisation level are you using for your compiler when >>> compiling GNUstep gui? >>> You should also try to print out the event (po theEvent and p *theEvent) >>> and inspect the window given in the event. This should be the window the >>> event gets send to. >>> >>> Could you please update your GNUstep installation to the latest release? >>> This makes it easier to compare the line numbers in the stack trace. >>> >>> Fred >>> >>> On 28.12.2013 22:30, Jamie Ramone wrote: >>> > What's common in both is self == nil (self=0x0) in NSWindow's >>> -sendEvent >>> > method. While that doesn't seem right, nil is a valid receiver as far >>> as >>> > the runtime's concerned. So I'n still unsure of the cause of the >>> segfault. >>> > Let me know what you find Greg. >>> > >>> > >>> > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone >>> wrote: >>> > >>> >> Here's the 2nd test: >>> >> >>> >> (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=, >>> theEvent=0x10e59a0) >>> >> >>> >> at NSWindow.m:4288 >>> >> 4288NSWindow.m: No such file or directory. >>> >> (gdb) bt >>> >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >>> >> theEvent=0x10e59a0) >>> >> >>> >> at NSWindow.m:4288 >>> >> #1 0x77201e8c in -[GSDragView(Private) >>> _handleDrag:slidePoint:] ( >>> >> self=0xad5c80, _cmd=, theEvent=0x1110160, >>> >> slidePoint=...) >>> >> at GSDragView.m:720 >>> >> #2 0x771e in -[GSDragView >>> >> dragImage:at:offset:event:pasteboard:source:slideBack:] >>> (self=0xad5c80, >>> >> _cmd=, anImage=0x7b2300, >>> >> screenLocation=..., initialOffset=..., event=0x8c7470, >>> >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') >>> >> at GSDragView.m:290 >>> >> #3 0x7049b254 in -[XGDragView >>> >> dragImage:at:offset:event:pasteboard:source:slideBack:] >>> (self=0xad5c80, >>> >> _cmd=, anImage=0x7b2300, >>> >> screenLocation=..., initialOffset=..., event=0x8c7470, >>> >> pboard=0xc49240, >>> >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 >>> >> #4 0x771d361a in -[NSWindow >>> >> dragImage:at:offset:event:pasteboard:source:slideBack:] >>> (self=0xc40900, >>> >> _cmd=, anImage=0x7b2300, >>> >> baseLocation=..., initialOffset=..., event=0x8c7470, >>> >> pboard=, sourceObject=, slideFlag=1 >>> >> '\001') >>> >> at NSWindow.m:4548 >>> >> #5 0x771bd7a8 in -[NSView >>> >> dragImage:at:offset:event:pasteboard:source:slideBack:] >>> (self=0xd35030, >>> >> _cmd=, anImage=0x7b2300, >>> >> viewLocation=..., initialOffset=..., event=0x8c7470, >>> >> pboard=, sourceObject=, slideFlag=1 >>> >> '\001') >>> >> at NSView.m:3858 >>> >> #6 0x77b3f569 in -[GormViewEditor >>> >> startConnectingObject:withEvent:] ( >>> >> self=0xd35030, _cmd=, anObject=, >>> >> theEvent=0x8c7470) at GormViewEditor.m:1203 >>> >> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:] >>> >> (self=0xd35030, >>> >> _cmd=, theEvent=0x8c7470) at >>> GormScrollViewEditor.m:123 >>> >> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900, >>> >> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790 >>> >> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0, >>> >> _cmd=) at NSApplication.m:1562 >>> >> #10 0x77032945 in NSApplicationMain (argc=, >>> >> argv=) at Functions.m:91 >>> >> #11 0x75ee676d in __libc_start_main () >>> >>from /lib/x86_64-linux-gnu/libc.so.6 >>> >> #12 0x00401965 in _start () >>> >> (gdb) >>> >> >>> >> Same as
Re: Serious GORM bug
Part of the problem could be with Dragon and drop itself. Try another application which uses Dragon to see if that fans. On some systems there might be a problem with the drag-and-drop daemon. On Saturday, December 28, 2013, Jamie Ramone wrote: > OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try > the most recent release. Wish me luck! :) > > > On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: > > Optimization??? I just use configure and the supplied makefile. Anyway, > I'm gonna completely wipe out the current GNUstep installation and build it > from scratch. I suspect some corruption crept in with that nasty system > crash I had. I reinstalled GNUstep on top of the old installation that > time. I'll first use the sources I already had and see if the bug goes > away. regardless, I'll update after that. Stand by for updates. > > > On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: > > I was not able to reproduce your problem on my system. Maybe more > detailed instructions would be helpful. What I noticed when looking at > your stack trace is that a lot of intermediate methods are left out > there. Which optimisation level are you using for your compiler when > compiling GNUstep gui? > You should also try to print out the event (po theEvent and p *theEvent) > and inspect the window given in the event. This should be the window the > event gets send to. > > Could you please update your GNUstep installation to the latest release? > This makes it easier to compare the line numbers in the stack trace. > > Fred > > On 28.12.2013 22:30, Jamie Ramone wrote: > > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent > > method. While that doesn't seem right, nil is a valid receiver as far as > > the runtime's concerned. So I'n still unsure of the cause of the > segfault. > > Let me know what you find Greg. > > > > > > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone > wrote: > > > >> Here's the 2nd test: > >> > >> (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=, > theEvent=0x10e59a0) > >> > >> at NSWindow.m:4288 > >> 4288NSWindow.m: No such file or directory. > >> (gdb) bt > >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > >> theEvent=0x10e59a0) > >> > >> at NSWindow.m:4288 > >> #1 0x77201e8c in -[GSDragView(Private) > _handleDrag:slidePoint:] ( > >> self=0xad5c80, _cmd=, theEvent=0x1110160, > >> slidePoint=...) > >> at GSDragView.m:720 > >> #2 0x771e in -[GSDragView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, > >> _cmd=, anImage=0x7b2300, > >> screenLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') > >> at GSDragView.m:290 > >> #3 0x7049b254 in -[XGDragView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, > >> _cmd=, anImage=0x7b2300, > >> screenLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=0xc49240, > >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 > >> #4 0x771d361a in -[NSWindow > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, > >> _cmd=, anImage=0x7b2300, > >> baseLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=, slideFlag=1 > >> '\001') > >> at NSWindow.m:4548 > >> #5 0x771bd7a8 in -[NSView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, > >> _cmd=, anImage=0x7b2300, > >> viewLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject= > -- 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
Re: Serious GORM bug
I'm already on the recent libs (and Gorm). I put it in /SystemLibrary/GNUstep.conf, Tis easier 2 uninstall this way ;-) In any case, no luck. Recent GNUstep, recent Gorm, old bug :-S I DID, however see failed tests in GUI...and looking at the logs it appears to be just because of the backend not being installed yet. Let me check...(goes off to tinker with the code)...Yep, that was it :P On Sat, Dec 28, 2013 at 9:51 PM, Ivan Vučica wrote: > When wiping GNUstep off your system (before a reinstall, of course!), > don't forget /etc/GNUstep.conf -- or something like that. > > > On Sun, Dec 29, 2013 at 12:37 AM, Jamie Ramone wrote: > >> OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try >> the most recent release. Wish me luck! :) >> >> >> On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: >> >>> Optimization??? I just use configure and the supplied makefile. Anyway, >>> I'm gonna completely wipe out the current GNUstep installation and build it >>> from scratch. I suspect some corruption crept in with that nasty system >>> crash I had. I reinstalled GNUstep on top of the old installation that >>> time. I'll first use the sources I already had and see if the bug goes >>> away. regardless, I'll update after that. Stand by for updates. >>> >>> >>> On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: >>> I was not able to reproduce your problem on my system. Maybe more detailed instructions would be helpful. What I noticed when looking at your stack trace is that a lot of intermediate methods are left out there. Which optimisation level are you using for your compiler when compiling GNUstep gui? You should also try to print out the event (po theEvent and p *theEvent) and inspect the window given in the event. This should be the window the event gets send to. Could you please update your GNUstep installation to the latest release? This makes it easier to compare the line numbers in the stack trace. Fred On 28.12.2013 22:30, Jamie Ramone wrote: > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent > method. While that doesn't seem right, nil is a valid receiver as far as > the runtime's concerned. So I'n still unsure of the cause of the segfault. > Let me know what you find Greg. > > > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone wrote: > >> Here's the 2nd test: >> >> (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=, theEvent=0x10e59a0) >> >> at NSWindow.m:4288 >> 4288NSWindow.m: No such file or directory. >> (gdb) bt >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >> theEvent=0x10e59a0) >> >> at NSWindow.m:4288 >> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] ( >> self=0xad5c80, _cmd=, theEvent=0x1110160, >> slidePoint=...) >> at GSDragView.m:720 >> #2 0x771e in -[GSDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> _cmd=, anImage=0x7b2300, >> screenLocation=..., initialOffset=..., event=0x8c7470, >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') >> at GSDragView.m:290 >> #3 0x7049b254 in -[XGDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> _cmd=, anImage=0x7b2300, >> screenLocation=..., initialOffset=..., event=0x8c7470, >> pboard=0xc49240, >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 >> #4 0x771d361a in -[NSWindow >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, >> _cmd=, anImage=0x7b2300, >> baseLocation=..., initialOffset=..., event=0x8c7470, >> pboard=, sourceObject=, slideFlag=1 >> '\001') >> at NSWindow.m:4548 >> #5 0x771bd7a8 in -[NSView >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, >> _cmd=, anImage=0x7b2300, >> viewLocation=..., initialOffset=..., event=0x8c7470, >> pboard=, sourceObject=, slideFlag=1 >> '\001') >> at NSView.m:3858 >> #6 0x77b3f569 in -[GormViewEditor >> startConnectingObject:withEvent:] ( >> self=0xd35030, _cmd=, anObject=, >> theEvent=0x8c7470) at GormViewEditor.m:1203 >> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:] >> (self=0xd35030, >> _cmd=, th
Re: Serious GORM bug
Dragons??? Are you doing acid Greg? :P Hmm, maybe there's a problem with drag & drop. I'll go ahead and check that. On Sun, Dec 29, 2013 at 1:40 AM, Gregory Casamento wrote: > Part of the problem could be with Dragon and drop itself. Try another > application which uses Dragon to see if that fans. On some systems there > might be a problem with the drag-and-drop daemon. > > > On Saturday, December 28, 2013, Jamie Ramone wrote: > >> OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try >> the most recent release. Wish me luck! :) >> >> >> On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: >> >> Optimization??? I just use configure and the supplied makefile. Anyway, >> I'm gonna completely wipe out the current GNUstep installation and build it >> from scratch. I suspect some corruption crept in with that nasty system >> crash I had. I reinstalled GNUstep on top of the old installation that >> time. I'll first use the sources I already had and see if the bug goes >> away. regardless, I'll update after that. Stand by for updates. >> >> >> On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: >> >> I was not able to reproduce your problem on my system. Maybe more >> detailed instructions would be helpful. What I noticed when looking at >> your stack trace is that a lot of intermediate methods are left out >> there. Which optimisation level are you using for your compiler when >> compiling GNUstep gui? >> You should also try to print out the event (po theEvent and p *theEvent) >> and inspect the window given in the event. This should be the window the >> event gets send to. >> >> Could you please update your GNUstep installation to the latest release? >> This makes it easier to compare the line numbers in the stack trace. >> >> Fred >> >> On 28.12.2013 22:30, Jamie Ramone wrote: >> > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent >> > method. While that doesn't seem right, nil is a valid receiver as far as >> > the runtime's concerned. So I'n still unsure of the cause of the >> segfault. >> > Let me know what you find Greg. >> > >> > >> > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone >> wrote: >> > >> >> Here's the 2nd test: >> >> >> >> (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=, >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> 4288NSWindow.m: No such file or directory. >> >> (gdb) bt >> >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >> >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> #1 0x77201e8c in -[GSDragView(Private) >> _handleDrag:slidePoint:] ( >> >> self=0xad5c80, _cmd=, theEvent=0x1110160, >> >> slidePoint=...) >> >> at GSDragView.m:720 >> >> #2 0x771e in -[GSDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') >> >> at GSDragView.m:290 >> >> #3 0x7049b254 in -[XGDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=0xc49240, >> >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 >> >> #4 0x771d361a in -[NSWindow >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, >> >> _cmd=, anImage=0x7b2300, >> >> baseLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=, slideFlag=1 >> >> '\001') >> >> at NSWindow.m:4548 >> >> #5 0x771bd7a8 in -[NSView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, >> >> _cmd=, anImage=0x7b2300, >> >> viewLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=> >> > > -- > 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
Re: Serious GORM bug
Gregory Casamento wrote: Part of the problem could be with Dragon and drop itself. Try another application which uses Dragon to see if that fans. On some systems there might be a problem with the drag-and-drop daemon. For the sanity of us all, stop dictating your mails, or scan a medical certificate that your fingers are too sore to type :) Although, well a Dungeon&Dragon game for GNUstep would bring us a lot of users ;) Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Am 29.12.2013 um 10:09 schrieb Riccardo Mottola : > Gregory Casamento wrote: >> Part of the problem could be with Dragon and drop itself. Try another >> application which uses Dragon to see if that fans. On some systems there >> might be a problem with the drag-and-drop daemon. > For the sanity of us all, stop dictating your mails, or scan a medical > certificate that your fingers are too sore to type :) > > Although, well a Dungeon&Dragon game for GNUstep would bring us a lot of > users ;) Yes that's it. The new goal for GNUstep :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Lol. Well, If I'm doing to dictate, I should at least proofread On Sunday, December 29, 2013, Riccardo Mottola wrote: > Gregory Casamento wrote: > >> Part of the problem could be with Dragon and drop itself. Try another >> application which uses Dragon to see if that fans. On some systems there >> might be a problem with the drag-and-drop daemon. >> > For the sanity of us all, stop dictating your mails, or scan a medical > certificate that your fingers are too sore to type :) > > Although, well a Dungeon&Dragon game for GNUstep would bring us a lot of > users ;) > > Riccardo > > -- 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
Re: Serious GORM bug
On 29 Dec 2013, at 12:04, Gregory Casamento wrote: > Well, If I'm doing to dictate, I should at least proofread ^ Good start... David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Yeah, I know. :( Any ideas with respect to what is wrong with drag and drop? On Sunday, December 29, 2013, David Chisnall wrote: > On 29 Dec 2013, at 12:04, Gregory Casamento > > > wrote: > > > Well, If I'm doing to dictate, I should at least proofread > ^ > > Good start... > > David > > > > > -- Sent from my Cray X1 > > -- 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
Re: Serious GORM bug
Not sure yet, but I'd like to note that the upgrade borked the alpha blending on all D&D images :-/ Still looking... Oh, any idea as to which app would be best suited for this test, is there a useful one in the examples tarball? On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento wrote: > Yeah, I know. :( Any ideas with respect to what is wrong with drag and > drop? > > > On Sunday, December 29, 2013, David Chisnall wrote: > >> On 29 Dec 2013, at 12:04, Gregory Casamento >> wrote: >> >> > Well, If I'm doing to dictate, I should at least proofread >> ^ >> >> Good start... >> >> David >> >> >> >> >> -- Sent from my Cray X1 >> >> > > -- > 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 > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
GWorkspace may be good. On Sunday, December 29, 2013, Jamie Ramone wrote: > Not sure yet, but I'd like to note that the upgrade borked the alpha > blending on all D&D images :-/ Still looking... > Oh, any idea as to which app would be best suited for this test, is there > a useful one in the examples tarball? > > > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < > greg.casame...@gmail.com 'greg.casame...@gmail.com');>> wrote: > >> Yeah, I know. :( Any ideas with respect to what is wrong with drag and >> drop? >> >> >> On Sunday, December 29, 2013, David Chisnall wrote: >> >>> On 29 Dec 2013, at 12:04, Gregory Casamento >>> wrote: >>> >>> > Well, If I'm doing to dictate, I should at least proofread >>> ^ >>> >>> Good start... >>> >>> David >>> >>> >>> >>> >>> -- Sent from my Cray X1 >>> >>> >> >> -- >> 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 >> >> > -- 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
Re: Serious GORM bug
I thought so. So far nothing. I've moved files and folders around, as well as color swatches and nothing. My only gripe is no alpha but apart from that, I'm not having any D&D troubles. In fact, the only app with this problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento wrote: > GWorkspace may be good. > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > >> Not sure yet, but I'd like to note that the upgrade borked the alpha >> blending on all D&D images :-/ Still looking... >> Oh, any idea as to which app would be best suited for this test, is there >> a useful one in the examples tarball? >> >> >> On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Yeah, I know. :( Any ideas with respect to what is wrong with drag and >>> drop? >>> >>> >>> On Sunday, December 29, 2013, David Chisnall wrote: >>> On 29 Dec 2013, at 12:04, Gregory Casamento wrote: > Well, If I'm doing to dictate, I should at least proofread ^ Good start... David -- Sent from my Cray X1 >>> >>> -- >>> 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 >>> >>> >> > > -- > 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
Re: Serious GORM bug
Moving files and folders around is not what I'm talking about try dragging something in from outside. GC On Sunday, December 29, 2013, Jamie Ramone wrote: > I thought so. So far nothing. I've moved files and folders around, as well > as color swatches and nothing. My only gripe is no alpha but apart from > that, I'm not having any D&D troubles. In fact, the only app with this > problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. > > > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < > greg.casame...@gmail.com 'greg.casame...@gmail.com');>> wrote: > >> GWorkspace may be good. >> >> >> On Sunday, December 29, 2013, Jamie Ramone wrote: >> >>> Not sure yet, but I'd like to note that the upgrade borked the alpha >>> blending on all D&D images :-/ Still looking... >>> Oh, any idea as to which app would be best suited for this test, is >>> there a useful one in the examples tarball? >>> >>> >>> On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> Yeah, I know. :( Any ideas with respect to what is wrong with drag and drop? On Sunday, December 29, 2013, David Chisnall wrote: > On 29 Dec 2013, at 12:04, Gregory Casamento > wrote: > > > Well, If I'm doing to dictate, I should at least proofread > ^ > > Good start... > > David > > > > > -- Sent from my Cray X1 > > -- 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 >>> >> >> -- >> 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 >> > > -- 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
Re: Serious GORM bug
Something from the outside? What do you mean, like from another app? But what, could you be more specific? Thanx. In any case here's my most recent test: made two new folders and dragged them around, into the shelf, from there inside of the other one, back home, same thing in revers order...nothing. The only thing that crashed GWorkspace was closing the Trash viewer. On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento wrote: > Moving files and folders around is not what I'm talking about try dragging > something in from outside. > > GC > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > >> I thought so. So far nothing. I've moved files and folders around, as >> well as color swatches and nothing. My only gripe is no alpha but apart >> from that, I'm not having any D&D troubles. In fact, the only app with this >> problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. >> >> >> On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> GWorkspace may be good. >>> >>> >>> On Sunday, December 29, 2013, Jamie Ramone wrote: >>> Not sure yet, but I'd like to note that the upgrade borked the alpha blending on all D&D images :-/ Still looking... Oh, any idea as to which app would be best suited for this test, is there a useful one in the examples tarball? On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < greg.casame...@gmail.com> wrote: > Yeah, I know. :( Any ideas with respect to what is wrong with drag > and drop? > > > On Sunday, December 29, 2013, David Chisnall wrote: > >> On 29 Dec 2013, at 12:04, Gregory Casamento >> wrote: >> >> > Well, If I'm doing to dictate, I should at least proofread >> ^ >> >> Good start... >> >> David >> >> >> >> >> -- Sent from my Cray X1 >> >> > > -- > 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 > > >>> >>> -- >>> 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 >>> >> >> > > -- > 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
Re: Serious GORM bug
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. Greg On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: > Something from the outside? What do you mean, like from another app? But > what, could you be more specific? Thanx. In any case here's my most recent > test: made two new folders and dragged them around, into the shelf, from > there inside of the other one, back home, same thing in revers > order...nothing. The only thing that crashed GWorkspace was closing the Trash > viewer. > > > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento > wrote: > Moving files and folders around is not what I'm talking about try dragging > something in from outside. > > GC > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > I thought so. So far nothing. I've moved files and folders around, as well as > color swatches and nothing. My only gripe is no alpha but apart from that, > I'm not having any D&D troubles. In fact, the only app with this problem is > GORM. I'll keep fiddling with GWorkspace and see if it shows up. > > > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento > wrote: > GWorkspace may be good. > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > Not sure yet, but I'd like to note that the upgrade borked the alpha blending > on all D&D images :-/ Still looking... > Oh, any idea as to which app would be best suited for this test, is there a > useful one in the examples tarball? > > > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento > wrote: > Yeah, I know. :( Any ideas with respect to what is wrong with drag and drop? > > > On Sunday, December 29, 2013, David Chisnall wrote: > On 29 Dec 2013, at 12:04, Gregory Casamento wrote: > > > Well, If I'm doing to dictate, I should at least proofread > ^ > > Good start... > > David > > > > > -- Sent from my Cray X1 > > > > -- > 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 > > > > > -- > 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 > > > > -- > 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
Re: Serious GORM bug
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. On Sun, Dec 29, 2013 at 5:58 PM, 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. > > Greg > > On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: > > > Something from the outside? What do you mean, like from another app? But > what, could you be more specific? Thanx. In any case here's my most recent > test: made two new folders and dragged them around, into the shelf, from > there inside of the other one, back home, same thing in revers > order...nothing. The only thing that crashed GWorkspace was closing the > Trash viewer. > > > > > > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > > Moving files and folders around is not what I'm talking about try > dragging something in from outside. > > > > GC > > > > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > > I thought so. So far nothing. I've moved files and folders around, as > well as color swatches and nothing. My only gripe is no alpha but apart > from that, I'm not having any D&D troubles. In fact, the only app with this > problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. > > > > > > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > > GWorkspace may be good. > > > > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > > Not sure yet, but I'd like to note that the upgrade borked the alpha > blending on all D&D images :-/ Still looking... > > Oh, any idea as to which app would be best suited for this test, is > there a useful one in the examples tarball? > > > > > > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > > Yeah, I know. :( Any ideas with respect to what is wrong with drag and > drop? > > > > > > On Sunday, December 29, 2013, David Chisnall wrote: > > On 29 Dec 2013, at 12:04, Gregory Casamento > wrote: > > > > > Well, If I'm doing to dictate, I should at least proofread > > ^ > > > > Good start... > > > > David > > > > > > > > > > -- Sent from my Cray X1 > > > > > > > > -- > > 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 > > > > > > > > > > -- > > 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 > > > > > > > > -- > > 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
Re: Serious GORM bug
Just dragged around folders between 2 viewer windows without a hitch. Let's have a look at the tabbed shelf, that holds just about anything. On Sun, Dec 29, 2013 at 6:02 PM, 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. > > > On Sun, Dec 29, 2013 at 5:58 PM, Gregory Casamento < > greg.casame...@gmail.com> 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. >> >> Greg >> >> On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: >> >> > Something from the outside? What do you mean, like from another app? >> But what, could you be more specific? Thanx. In any case here's my most >> recent test: made two new folders and dragged them around, into the shelf, >> from there inside of the other one, back home, same thing in revers >> order...nothing. The only thing that crashed GWorkspace was closing the >> Trash viewer. >> > >> > >> > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> > Moving files and folders around is not what I'm talking about try >> dragging something in from outside. >> > >> > GC >> > >> > >> > On Sunday, December 29, 2013, Jamie Ramone wrote: >> > I thought so. So far nothing. I've moved files and folders around, as >> well as color swatches and nothing. My only gripe is no alpha but apart >> from that, I'm not having any D&D troubles. In fact, the only app with this >> problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. >> > >> > >> > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> > GWorkspace may be good. >> > >> > >> > On Sunday, December 29, 2013, Jamie Ramone wrote: >> > Not sure yet, but I'd like to note that the upgrade borked the alpha >> blending on all D&D images :-/ Still looking... >> > Oh, any idea as to which app would be best suited for this test, is >> there a useful one in the examples tarball? >> > >> > >> > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> > Yeah, I know. :( Any ideas with respect to what is wrong with drag >> and drop? >> > >> > >> > On Sunday, December 29, 2013, David Chisnall wrote: >> > On 29 Dec 2013, at 12:04, Gregory Casamento >> wrote: >> > >> > > Well, If I'm doing to dictate, I should at least proofread >> > ^ >> > >> > Good start... >> > >> > David >> > >> > >> > >> > >> > -- Sent from my Cray X1 >> > >> > >> > >> > -- >> > 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 >> > >> > >> > >> > >> > -- >> > 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 >> > >> > >> > >> > -- >> > 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
Re: Serious GORM bug
Hmm, I was able to drag a red color swatch from Ink's color panel to the tabbed shelf. Then wrote some text in black and selected one letter. Finally I dragged the swatch from the shelf onto the selected text, which changed from black to red as expected. Still poking around... On Sun, Dec 29, 2013 at 6:06 PM, Jamie Ramone wrote: > Just dragged around folders between 2 viewer windows without a hitch. > Let's have a look at the tabbed shelf, that holds just about anything. > > > On Sun, Dec 29, 2013 at 6:02 PM, 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. >> >> >> On Sun, Dec 29, 2013 at 5:58 PM, Gregory Casamento < >> greg.casame...@gmail.com> 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. >>> >>> Greg >>> >>> On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: >>> >>> > Something from the outside? What do you mean, like from another app? >>> But what, could you be more specific? Thanx. In any case here's my most >>> recent test: made two new folders and dragged them around, into the shelf, >>> from there inside of the other one, back home, same thing in revers >>> order...nothing. The only thing that crashed GWorkspace was closing the >>> Trash viewer. >>> > >>> > >>> > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> > Moving files and folders around is not what I'm talking about try >>> dragging something in from outside. >>> > >>> > GC >>> > >>> > >>> > On Sunday, December 29, 2013, Jamie Ramone wrote: >>> > I thought so. So far nothing. I've moved files and folders around, as >>> well as color swatches and nothing. My only gripe is no alpha but apart >>> from that, I'm not having any D&D troubles. In fact, the only app with this >>> problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. >>> > >>> > >>> > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> > GWorkspace may be good. >>> > >>> > >>> > On Sunday, December 29, 2013, Jamie Ramone wrote: >>> > Not sure yet, but I'd like to note that the upgrade borked the alpha >>> blending on all D&D images :-/ Still looking... >>> > Oh, any idea as to which app would be best suited for this test, is >>> there a useful one in the examples tarball? >>> > >>> > >>> > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> > Yeah, I know. :( Any ideas with respect to what is wrong with drag >>> and drop? >>> > >>> > >>> > On Sunday, December 29, 2013, David Chisnall wrote: >>> > On 29 Dec 2013, at 12:04, Gregory Casamento >>> wrote: >>> > >>> > > Well, If I'm doing to dictate, I should at least proofread >>> > ^ >>> > >>> > Good start... >>> > >>> > David >>> > >>> > >>> > >>> > >>> > -- Sent from my Cray X1 >>> > >>> > >>> > >>> > -- >>> > 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 >>> > >>> > >>> > >>> > >>> > -- >>> > 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 >>> > >>> > >>> > >>> > -- >>> > 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
Re: Serious GORM bug
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. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
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 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. > > Fred > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
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 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
Re: Serious GORM bug
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=, theEvent=0xe121e0) at NSWindow.m:4414 4414NSWindow.m: No such file or directory. (gdb) bt #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xe121e0) at NSWindow.m:4414 #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] ( self=0xc55d00, _cmd=, theEvent=0x1061780, slidePoint=...) at GSDragView.m:720 #2 0x771ed20e in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=, sourceObject=0xf2e5f0, slideFlag=1 '\001') at GSDragView.m:290 #3 0x7045e344 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=0x9d9470, sourceObject=0xf2e5f0, slideFlag=1 '\001') at XGDragView.m:228 #4 0x771bebda in -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb140b0, _cmd=, anImage=0x9dc150, baseLocation=..., initialOffset=..., event=0x11073a0, pboard=, sourceObject=, slideFlag=1 '\001') at NSWindow.m:4674 #5 0x771a8c08 in -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xf2e5f0, _cmd=, anImage=0x9dc150, ---Type to continue, or q to quit--- viewLocation=..., initialOffset=..., event=0x11073a0, pboard=, sourceObject=, slideFlag=1 '\001') at NSView.m:3860 #6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xf2e5f0, _cmd=, theEvent=0x11073a0) at GormObjectEditor.m:481 #7 0x771ca953 in -[NSWindow sendEvent:] (self=0xb140b0, _cmd=, theEvent=0x11073a0) at NSWindow.m:3896 #8 0x770343e3 in -[NSApplication run] (self=0x8c8450, _cmd=) at NSApplication.m:1562 #9 0x770130d5 in NSApplicationMain (argc=, argv=) at Functions.m:91 #10 0x75eab76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x00401965 in _start () (gdb) On Sun, Dec 29, 2013 at 6:50 PM, Fred Kiefer 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 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
Re: Serious GORM bug
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=, theEvent=0xe121e0) > at NSWindow.m:4414 > 4414NSWindow.m: No such file or directory. > (gdb) bt > #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > theEvent=0xe121e0) > at NSWindow.m:4414 > #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] ( > self=0xc55d00, _cmd=, theEvent=0x1061780, slidePoint=...) > at GSDragView.m:720 > #2 0x771ed20e in -[GSDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > _cmd=, anImage=0x9dc150, > screenLocation=..., initialOffset=..., event=0x11073a0, > pboard=, sourceObject=0xf2e5f0, slideFlag=1 '\001') > at GSDragView.m:290 > #3 0x7045e344 in -[XGDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > _cmd=, anImage=0x9dc150, > screenLocation=..., initialOffset=..., event=0x11073a0, > pboard=0x9d9470, > sourceObject=0xf2e5f0, slideFlag=1 '\001') at XGDragView.m:228 > #4 0x771bebda in -[NSWindow > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb140b0, > _cmd=, anImage=0x9dc150, > baseLocation=..., initialOffset=..., event=0x11073a0, > pboard=, sourceObject=, slideFlag=1 > '\001') > at NSWindow.m:4674 > #5 0x771a8c08 in -[NSView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xf2e5f0, > _cmd=, anImage=0x9dc150, > ---Type to continue, or q to quit--- > viewLocation=..., initialOffset=..., event=0x11073a0, > pboard=, sourceObject=, slideFlag=1 > '\001') > at NSView.m:3860 > #6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xf2e5f0, > _cmd=, theEvent=0x11073a0) at GormObjectEditor.m:481 > #7 0x771ca953 in -[NSWindow sendEvent:] (self=0xb140b0, > _cmd=, theEvent=0x11073a0) at NSWindow.m:3896 > #8 0x770343e3 in -[NSApplication run] (self=0x8c8450, > _cmd=) at NSApplication.m:1562 > #9 0x770130d5 in NSApplicationMain (argc=, > argv=) at Functions.m:91 > #10 0x75eab76d in __libc_start_main () >from /lib/x86_64-linux-gnu/libc.so.6 > #11 0x00401965 in _start () > (gdb) > > > > On Sun, Dec 29, 2013 at 6:50 PM, Fred Kiefer 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 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 Jami
Re: Serious GORM bug
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 => (0x7fff0cfff000) libGormCore.so.1 => /SystemLibrary/Libraries/libGormCore.so.1 (0x7fd04788e000) libGorm.so.1 => /SystemLibrary/Libraries/libGorm.so.1 (0x7fd04767e000) libGormPrefs.so.1 => /SystemLibrary/Libraries/libGormPrefs.so.1 (0x7fd047465000) libgnustep-gui.so.0.24 => /SystemLibrary/Libraries/libgnustep-gui.so.0.24 (0x7fd046c46000) libgnustep-base.so.1.24 => /SystemLibrary/Libraries/libgnustep-base.so.1.24 (0x7fd04649b000) libobjc.so.3 => /usr/lib/x86_64-linux-gnu/libobjc.so.3 (0x7fd04625f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fd046049000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd045c89000) libGormObjCHeaderParser.so.1 => /SystemLibrary/Libraries/libGormObjCHeaderParser.so.1 (0x7fd045a7b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd04585e000) libicuuc.so.48 => /usr/lib/libicuuc.so.48 (0x7fd0454f4000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7fd0452cb000) libgif.so.4 => /usr/lib/x86_64-linux-gnu/libgif.so.4 (0x7fd0450c2000) libtiff.so.4 => /usr/lib/x86_64-linux-gnu/libtiff.so.4 (0x7fd044e5e000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x7fd044c0d000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fd044911000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x7fd044655000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7fd0443d6000) libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x7fd04419a000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x7fd043e3e000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7fd043c35000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd043a31000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fd04381a000) libicui18n.so.48 => /usr/lib/libicui18n.so.48 (0x7fd043451000) /lib64/ld-linux-x86-64.so.2 (0x7fd047bf5000) libicudata.so.48 => /usr/lib/libicudata.so.48 (0x7fd0420e1000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fd041de) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x7fd041bcf000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7fd0419bc000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7fd0417b8000) On Mon, Dec 30, 2013 at 1:55 PM, Fred Kiefer 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=, > theEvent=0xe121e0) > > at NSWindow.m:4414 > > 4414NSWindow.m: No such file or directory. > > (gdb) bt > > #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > > theEvent=0xe121e0) > > at NSWindow.m:4414 > > #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] > ( > > self=0xc55d00, _cmd=, theEvent=0x1061780, > slidePoint=...) > > at GSDragView.m:720 > > #2 0x771ed20e in -[GSDragView > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > > _cmd=, anImage=0x9dc150, > > screenLocation=..., initialOffset=..., event=0x11073a0, > > pboard=, sourceObject=0xf2e5f0, slideFlag=1 '\001') > > at GSDragView.m:290 > > #3 0x7045e344 in -[XGDragView > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > > _cmd=, anImage=0x9dc150, > > screenLocation=..., initialOffs
Re: Serious GORM bug
El lun, 30-12-2013 a las 15:30 -0200, Jamie Ramone escribió: > 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 => (0x7fff0cfff000) linux-vdso.so is used only in recent kernels at 64 bits machines. So, could be a problem with this library? Searching on internet, seems there are people having problems with this. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Hmm, interesting. What could be a good workaround? Can it safely be removed or downgraded? Keep in mind that I'm on Ubuntu 12.04. On Mon, Dec 30, 2013 at 3:27 PM, Germán Arias wrote: > El lun, 30-12-2013 a las 15:30 -0200, Jamie Ramone escribió: > > 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 => (0x7fff0cfff000) > > > linux-vdso.so is used only in recent kernels at 64 bits machines. So, > could be a problem with this library? Searching on internet, seems there > are people having problems with this. > > Germán. > > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
El lun, 30-12-2013 a las 16:48 -0200, Jamie Ramone escribió: > Hmm, interesting. What could be a good workaround? Can it safely be > removed or downgraded? Keep in mind that I'm on Ubuntu 12.04. I'm not sure, but this could be a problem in the version of libc that has Ubuntu 12.04. Unfortunately there isn't an update for this package in 12.04. I only can think to test it (maybe in a virtual machine) with a more recent version of Ubuntu. Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
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 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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
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) Program received signal SIGSEGV, Segmentation fault. -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x1080810) at NSWindow.m:4409 4409NSWindow.m: No such file or directory. (gdb) bt #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x1080810) at NSWindow.m:4409 #1 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] (self=0xb4aa70, _cmd=, theEvent=0x1052960, slidePoint=...) at GSDragView.m:720 #2 0x771e88e3 in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, _cmd=, anImage=0x8866a0, screenLocation=..., initialOffset=..., event=0xab2760, pboard=, sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 #3 0x72208769 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=self@entry=0xb4aa70, _cmd=_cmd@entry=0x775f0fb0 <_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 0x771bfc36 in -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] (self=self@entry=0xad8630, _cmd=_cmd@entry=0x775e6730 <_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 0x771a9464 in -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=self@entry=0xd536c0, _cmd=_cmd@entry=0x77da5ff0 <_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 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, _cmd=, theEvent=0xab2760) at GormObjectEditor.m:481 #7 0x771c93d0 in -[NSWindow sendEvent:] (self=0xad8630, _cmd=, theEvent=0xab2760) at NSWindow.m:3896 #8 0x7704c6f3 in -[NSApplication run] (self=0x87e2f0, _cmd=) at NSApplication.m:1562 #9 0x7702cfe5 in NSApplicationMain (argc=, argv=) at Functions.m:91 #10 0x75ed5de5 in __libc_start_main (main=0x4019c0 , argc=1, ubp_av=0x7fffdc78, init=, fini=, rtld_fini=, stack_end=0x7fffdc68) at libc-start.c:260 #11 0x00401a05 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 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 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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Am 04.01.2014 um 00:17 schrieb Jamie Ramone : > 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). > Program received signal SIGSEGV, Segmentation fault. > -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x1080810) > at NSWindow.m:4409 > 4409NSWindow.m: No such file or directory. Again you seem to have deleted the source code. Why do you keep on doing this. > (gdb) bt > #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > 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? > #1 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] > (self=0xb4aa70, _cmd=, theEvent=0x1052960, > slidePoint=...) at GSDragView.m:720 > #2 0x771e88e3 in -[GSDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, > _cmd=, anImage=0x8866a0, screenLocation=..., > initialOffset=..., event=0xab2760, pboard=, > sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 > #3 0x72208769 in -[XGDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xb4aa70, > _cmd=_cmd@entry=0x775f0fb0 <_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 0x771bfc36 in -[NSWindow > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xad8630, > _cmd=_cmd@entry=0x775e6730 <_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 0x771a9464 in -[NSView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xd536c0, > _cmd=_cmd@entry=0x77da5ff0 <_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 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, > _cmd=, theEvent=0xab2760) > at GormObjectEditor.m:481 > #7 0x771c93d0 in -[NSWindow sendEvent:] (self=0xad8630, > _cmd=, theEvent=0xab2760) at NSWindow.m:3896 > #8 0x7704c6f3 in -[NSApplication run] (self=0x87e2f0, > _cmd=) at NSApplication.m:1562 > #9 0x7702cfe5 in NSApplicationMain (argc=, > argv=) at Functions.m:91 > #10 0x75ed5de5 in __libc_start_main (main=0x4019c0 , argc=1, > ubp_av=0x7fffdc78, init=, > fini=, rtld_fini=, > stack_end=0x7fffdc68) at libc-start.c:260 > #11 0x00401a05 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 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 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-appi
Re: Serious GORM bug
On Sat, Jan 4, 2014 at 7:59 AM, Fred Kiefer wrote: > > Am 04.01.2014 um 00:17 schrieb Jamie Ramone : > > 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=, > theEvent=0x1080810) at NSWindow.m:4409 > 4409NSWindow.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=, > 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 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] > (self=0xb4aa70, _cmd=, theEvent=0x1052960, > slidePoint=...) at GSDragView.m:720 > #2 0x771e88e3 in -[GSDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, > _cmd=, anImage=0x8866a0, screenLocation=..., > initialOffset=..., event=0xab2760, pboard=, > sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 > #3 0x72208769 in -[XGDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xb4aa70, > > _cmd=_cmd@entry=0x775f0fb0 <_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 0x771bfc36 in -[NSWindow > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xad8630, > > _cmd=_cmd@entry=0x775e6730 <_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 0x771a9464 in -[NSView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xd536c0, > > _cmd=_cmd@entry=0x77da5ff0 <_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 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, > _cmd=, theEvent=0xab2760) > at GormObjectEditor.m:481 > #7 0x771c93d0 in -[NSWindow sendEvent:] (self=0xad8630, > _cmd=, theEvent=0xab2760) at NSWindow.m:3896 > #8 0x7704c6f3 in -[NSApplication run] (self=0x87e2f0, > _cmd=) at NSApplication.m:1562 > #9 0x7702cfe5 in NSApplicationMain (argc=, > argv=) at Functions.m:91 > #10 0x75ed5de5 in __libc_start_main (main=0x4019c0 , argc=1, > ubp_av=0x7fffdc78, init=, > fini=, rtld_fini=, > stack_end=0x7fffdc68) at libc-start.c:260 > #11 0x00401a05 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 wrote: > >> So, I'll have to wait for 14 to come out then. I can live wi
Re: Serious GORM bug
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 > > > wrote: > >> >> Am 04.01.2014 um 00:17 schrieb Jamie Ramone >> >> >: >> >> 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=, >> theEvent=0x1080810) at NSWindow.m:4409 >> 4409NSWindow.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=, >> 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 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] > (self=0xb4aa70, _cmd=, theEvent=0x1052960, > slidePoint=...) at GSDragView.m:720 > #2 0x771e88e3 in -[GSDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, > _cmd=, anImage=0x8866a0, screenLocation=..., > initialOffset=..., event=0xab2760, pboard=, > sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 > #3 0x72208769 in -[XGDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xb4aa70, > > _cmd=_cmd@entry=0x775f0fb0 <_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 0x771bfc36 in -[NSWindow > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xad8630, > > _cmd=_cmd@entry=0x775e6730 <_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 0x771a9464 in -[NSView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xd536c0, > > _cmd=_cmd@entry=0x77da5ff0 <_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 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, > _cmd=, theEvent=0xab2760) > at GormObjectEditor.m:481 > #7 0x771c93d0 in -[NSWindow sendEvent:] (self=0xad8630, > _cmd=, theEvent=0xab2760) at NSWindow.m:3896 > #8 0x7704c6f3 in -[NSApplication run] (self=0x87e2f0, > _cmd=) at NSApplication.m:1562 > #9 0x7702cfe5 in NSApplicationMain (argc=, > argv=) at Functions.m:91 > #10 0x75ed5de5 in __libc_start_main (main=0x4019c0 , argc=1, > ubp_av=0x7fffdc78, init=, > fini=, rtld_fini=, > stack_end=0x7fff
Re: Serious GORM bug
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 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 wrote: >> >>> >>> Am 04.01.2014 um 00:17 schrieb Jamie Ramone : >>> >>> 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=, >>> theEvent=0x1080810) at NSWindow.m:4409 >>> 4409NSWindow.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=, >>> 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 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] >> (self=0xb4aa70, _cmd=, theEvent=0x1052960, >> slidePoint=...) at GSDragView.m:720 >> #2 0x771e88e3 in -[GSDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, >> _cmd=, anImage=0x8866a0, screenLocation=..., >> initialOffset=..., event=0xab2760, pboard=, >> sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 >> #3 0x72208769 in -[XGDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xb4aa70, >> >> _cmd=_cmd@entry=0x775f0fb0 <_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 0x771bfc36 in -[NSWindow >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xad8630, >> >> _cmd=_cmd@entry=0x775e6730 <_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 0x771a9464 in -[NSView >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xd536c0, >> >> _cmd=_cmd@entry=0x77da5ff0 <_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 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, >> _cmd=, theEvent=0xab2760) >> at GormObjectEditor.m:481 >> #7 0x7
Re: Serious GORM bug
On 04.01.2014 12:45, Jamie Ramone wrote: > On Sat, Jan 4, 2014 at 7:59 AM, Fred Kiefer wrote: >> Am 04.01.2014 um 00:17 schrieb Jamie Ramone : >> >> 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. I am back at my computer and found the source of this message. You have a window manager that uses double parent windows and there we had a left over NSLog call. I turned that into NSDebugLLog. Sadly this wont help with your real issue. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
