Re: Next GNUstep release?
Hi, If these exceptions were Uncaught exception NSInvalidArgumentException, reason: NSObject(class) does not recognize type the issue is fixed now (the latest base changes had inadvertently made GSObjCAllSubclassesOfClass return all superclasses of the class). The problem on Linux/x86 is now solved. I will check the Linux/MIPS ass soon as possible. Riccardi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
inconsistency exception with Grr on Linux/MIPS
Hi, I am a bit clueless, I get an exception when starting Grr on Linux/MIPS (the small Letux 400). Grr works for me however on other platforms like x86 and SPARC. Also, Grr used to work on the Letux too, I still have the saved articles I read in the past. Something in the recent (2-3 weeks at most) changes in Core upset it, do you have any idea? I made a clean compilation of core, RSSKit and Grr. 2010-05-02 12:40:58.703 Grr[3607] Tree Database Component starting up... 2010-05-02 12:40:58.754 Grr[3607] Article.m:38 Assertion failed in Article(instance), method initWithDictionary:. Cannot initialise an article from the nil dictionary 2010-05-02 12:40:58.758 Grr[3607] Problem posting notification: NAME:NSInternalInconsistencyException REASON:Article.m:38 Assertion failed in Article(instance), method initWithDictionary:. Cannot initialise an article from the nil dictionary INFO:(nil) Maybe somebody can reproduce this problem on a machine were debugging is more comfortable? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Hi, Hi, I am a bit clueless, I get an exception when starting Grr on Linux/MIPS (the small Letux 400). Grr works for me however on other platforms like x86 and SPARC. Also, Grr used to work on the Letux too, I still have the saved articles I read in the past. Something in the recent (2-3 weeks at most) changes in Core upset it, do you have any idea? I made a clean compilation of core, RSSKit and Grr. correction: it fails now on OpenBSD/SPARC too now. And I am sure that it worked there too! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Am 02.05.2010 14:44, schrieb Riccardo Mottola: >> I am a bit clueless, I get an exception when starting Grr on >> Linux/MIPS (the small Letux 400). >> Grr works for me however on other platforms like x86 and SPARC. >> Also, Grr used to work on the Letux too, I still have the saved >> articles I read in the past. >> >> Something in the recent (2-3 weeks at most) changes in Core upset it, >> do you have any idea? I made a clean compilation of core, RSSKit and Grr. > correction: it fails now on OpenBSD/SPARC too now. And I am sure that it > worked there too! I tried to look at the code to understand where the assertion comes from, but failed to understand where the Article objects actually get created. It really would help, if you could send a back trace. Most likely the whole problem comes from a corrupt file. Have you tried moving all your stored articles away? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Hi, I tried to look at the code to understand where the assertion comes from, but failed to understand where the Article objects actually get created. It really would help, if you could send a back trace. Most likely the whole problem comes from a corrupt file. Have you tried moving all your stored articles away Fred, I did not try, but I was wrong. Somehow the original files are not compatible on some platforms anymore. I follow the same feeds on my computers, so the articles are the same. On the small Letux, removing the articles database made the application start again. Subscribing to a feed, reading articles, reopening the application works. Something in base changed perhaps, since there were no Grr changes in the last month. Anyway, since it is coherent with itself, it is fine. On Sparc the application starts again too after removing defaults and articles DB, however other bugs show up which I report separately. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Hi I tried to look at the code to understand where the assertion comes from, but failed to understand where the Article objects actually get created. It really would help, if you could send a back trace. Most likely the whole problem comes from a corrupt file. Have you tried moving all your stored articles away? I removed everything, started the application subscribed to a feed (I performed the same operation on LInux/MIPS without troubles) but on quit of the applicaiton I get a crash which I do not get on other platforms. Could be this a Grr issue hidden on other platforms? Or even a core issue? Program received signal SIGBUS, Bus error. objc_msg_lookup (receiver=0x9c7250ff, op=0xec59b78) at sendmsg.c:224 224 result = sarray_get_safe (receiver->class_pointer->dtable, (gdb) bt #0 objc_msg_lookup (receiver=0x9c7250ff, op=0xec59b78) at sendmsg.c:224 #1 0x0e89f918 in -[NSWindow dealloc] () from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 #2 0x0d3944c8 in -[NSObject release] () from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 #3 0x0e72a654 in -[NSApplication dealloc] (self=0xc9aa388, _cmd=0xd73b2b4) at NSApplication.m:1220 #4 0x0d3944c8 in -[NSObject release] () from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 #5 0x0e7306dc in -[NSApplication replyToApplicationShouldTerminate:] ( self=0xc9aa388, _cmd=0xe8b45f8, shouldTerminate=1 '\001') at NSApplication.m:3459 #6 0x0e73041c in -[NSApplication terminate:] (self=0xc9aa388, _cmd=0xec765f0, sender=0x8a53a88) at NSApplication.m:3412 #7 0x0e72d228 in -[NSApplication sendAction:to:from:] (self=0xc9aa388, _cmd=0xec2b434, aSelector=0xec765f0, aTarget=0x0, sender=0x8a53a88) at NSApplication.m:2193 #8 0x0e7e98d4 in -[NSMenu performActionForItemAtIndex:] () from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 #9 0x0e7f1b4c in -[NSMenuView trackWithEvent:] (self=0x90b9108, _cmd=0x8a52d08, event=0x8a53e88) at NSMenuView.m:1642 #10 0x0e7f1cb4 in -[NSMenuView mouseDown:] (self=0x90b9108, _cmd=0xec5ac20, theEvent=0x8a52d08) at NSMenuView.m:1687 #11 0x0e8a9d0c in -[NSWindow sendEvent:] () from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 #12 0x0e72cc94 in -[NSApplication sendEvent:] (self=0xc9aa388, _cmd=0xebfdba0, theEvent=0x8a52d08) at NSApplication.m:2068 #13 0x0e72b594 in -[NSApplication run] (self=0xc9aa388, _cmd=0xebf65d8) at NSApplication.m:1530 #14 0x0e70d32c in NSApplicationMain (argc=202182728, argv=0xf7ff80d4) at Functions.m:74 #15 0x0001661c in gnustep_base_user_main () #16 0x0d3c41f0 in main (argc=1, argv=0xf7ff80d4, env=0xf7ff80dc) at NSProcessInfo.m:910 #17 0x00011ab4 in ___start () #18 0x000119e0 in _start () #19 0x000119e0 in _start () Previous frame identical to this frame (corrupt stack?) It seems to me an action is NIL and this causes a crash on SPARC. I rememebr some limitations there regarding NIL objects. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Am 02.05.2010 23:46, schrieb Riccardo Mottola: > Hi, >> I tried to look at the code to understand where the assertion comes >> from, but failed to understand where the Article objects actually get >> created. It really would help, if you could send a back trace. >> >> Most likely the whole problem comes from a corrupt file. Have you tried >> moving all your stored articles away >> > Fred, I did not try, but I was wrong. Somehow the original files are not > compatible on some platforms anymore. I follow the same feeds on my > computers, so the articles are the same. > > On the small Letux, removing the articles database made the application > start again. Subscribing to a feed, reading articles, reopening the > application works. Something in base changed perhaps, since there were > no Grr changes in the last month. Anyway, since it is coherent with > itself, it is fine. > > On Sparc the application starts again too after removing defaults and > articles DB, however other bugs show up which I report separately. Great that this was so simple to resolve. Do I understand this correctly? You tried to load the old file previously created on the same platform and now you cannot load them on the Letux, but they still work on other platforms. Or is this broken on all platforms. And how about the exchange between different platforms. Did this use to work and is it now working? What is your on disk format? In which class may I find it? Sorry, but with the separate RSSKit this project is a bit confusing to me. Does the on disk format contain binary data like int or float and how are they written/read? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: inconsistency exception with Grr on Linux/MIPS
Without a line number in the [NSWindow dealloc] it is hard to tell what is going on. It could be everything. Could you do an "up" in gdb and report back what where the error is happening? I would guess that it is the delegate, somehow it is always the delegates that are causing trouble. Most likely the object has already been dealloced and now it is referenced again. If this is the case then we have an application issue here. You should remove the delegate from the window as soon as that object goes away. But currently we don't know, it could still be a gui issue and that would be an important one to remove before the release. Am 03.05.2010 00:09, schrieb Riccardo Mottola: > I removed everything, started the application subscribed to a feed (I > performed the same operation on LInux/MIPS without troubles) but on quit > of the applicaiton I get a crash which I do not get on other platforms. > > Could be this a Grr issue hidden on other platforms? Or even a core issue? > > Program received signal SIGBUS, Bus error. > objc_msg_lookup (receiver=0x9c7250ff, op=0xec59b78) at sendmsg.c:224 > 224 result = sarray_get_safe (receiver->class_pointer->dtable, > (gdb) bt > #0 objc_msg_lookup (receiver=0x9c7250ff, op=0xec59b78) at sendmsg.c:224 > #1 0x0e89f918 in -[NSWindow dealloc] () >from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 > #2 0x0d3944c8 in -[NSObject release] () >from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 > #3 0x0e72a654 in -[NSApplication dealloc] (self=0xc9aa388, _cmd=0xd73b2b4) > at NSApplication.m:1220 > #4 0x0d3944c8 in -[NSObject release] () >from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 > #5 0x0e7306dc in -[NSApplication replyToApplicationShouldTerminate:] ( > self=0xc9aa388, _cmd=0xe8b45f8, shouldTerminate=1 '\001') > at NSApplication.m:3459 > #6 0x0e73041c in -[NSApplication terminate:] (self=0xc9aa388, > _cmd=0xec765f0, > sender=0x8a53a88) at NSApplication.m:3412 > #7 0x0e72d228 in -[NSApplication sendAction:to:from:] (self=0xc9aa388, > _cmd=0xec2b434, aSelector=0xec765f0, aTarget=0x0, sender=0x8a53a88) > at NSApplication.m:2193 > #8 0x0e7e98d4 in -[NSMenu performActionForItemAtIndex:] () >from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 > #9 0x0e7f1b4c in -[NSMenuView trackWithEvent:] (self=0x90b9108, > _cmd=0x8a52d08, event=0x8a53e88) at NSMenuView.m:1642 > #10 0x0e7f1cb4 in -[NSMenuView mouseDown:] (self=0x90b9108, _cmd=0xec5ac20, > theEvent=0x8a52d08) at NSMenuView.m:1687 > #11 0x0e8a9d0c in -[NSWindow sendEvent:] () >from /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.17 > #12 0x0e72cc94 in -[NSApplication sendEvent:] (self=0xc9aa388, > _cmd=0xebfdba0, > theEvent=0x8a52d08) at NSApplication.m:2068 > #13 0x0e72b594 in -[NSApplication run] (self=0xc9aa388, _cmd=0xebf65d8) > at NSApplication.m:1530 > #14 0x0e70d32c in NSApplicationMain (argc=202182728, argv=0xf7ff80d4) > at Functions.m:74 > #15 0x0001661c in gnustep_base_user_main () > #16 0x0d3c41f0 in main (argc=1, argv=0xf7ff80d4, env=0xf7ff80dc) > at NSProcessInfo.m:910 > #17 0x00011ab4 in ___start () > #18 0x000119e0 in _start () > #19 0x000119e0 in _start () > Previous frame identical to this frame (corrupt stack?) > > > It seems to me an action is NIL and this causes a crash on SPARC. I > rememebr some limitations there regarding NIL objects. > > Riccardo > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
