[bug #42782] Crash when loading a gorm file
Follow-up Comment #5, bug #42782 (project gnustep): This looks like the image loadign is failing for you and then Gorm tries to use the nil value to extract the size of the image. Because of a compiler bug this then results in a segmentation fault. In the second init... method there was already a check for that case. I added one in that method as well and cleaned up the code a bit. Please update SVN and give it another try. The more interesting question here is why does the image loading fail. Or the even more basic one, which image is it trying to load? I could not find one in the gorm file you attached to this bug report. And in gdb I don't see Gorm calling this method at all when loading your Gorm file. For this reason I leave this bug in the open state. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #6, bug #42782 (project gnustep): Gorm doesn't crash now but it doesn't load the file either. An alert panel is shown with title Alert and No information as message. The image file is, oddly enough, data.info. Here's the backtrace when this method is reached: Breakpoint 1, -[GormImage initWithData:withFileName:inWrapper:] ( self=0x9010440, _cmd=0xb7fae9a0 _OBJC_SELECTOR_TABLE+32, aData=0x81a0498, aName=0x9028d60, flag=1 ' 01') at GormImage.m:84 84[smallImage setSize: NSMakeSize(70, originalSize.height / ratioW)]; (gdb) po aName data.info (gdb) bt #0 -[GormImage initWithData:withFileName:inWrapper:] (self=0x9010440, _cmd=0xb7fae9a0 _OBJC_SELECTOR_TABLE+32, aData=0x81a0498, aName=0x9028d60, flag=1 ' 01') at GormImage.m:84 #1 0xb7f15136 in +[GormImage imageForData:withFileName:inWrapper:] ( self=0xb7faea60 _OBJC_Class_GormImage, _cmd=0xb7fd9238 _OBJC_SELECTOR_TABLE+952, aData=0x81a0498, aName=0x9028d60, flag=1 ' 01') at GormImage.m:56 #2 0xb7f46a2b in -[GormWrapperLoader loadFileWrapper:withDocument:] ( self=0x8b1b310, _cmd=0xb2c26980 _OBJC_SELECTOR_TABLE+1216, wrapper=0x9082728, doc=0x8544568) at GormWrapperLoader.m:87 #3 0xb2c1fd2f in -[GormGormWrapperLoader loadFileWrapper:withDocument:] ( self=0x8b1b310, _cmd=0xb7fa4208 _OBJC_SELECTOR_TABLE+3336, wrapper=0x9082728, doc=0x8544568) at GormGormWrapperLoader.m:361 #4 0xb7f071eb in -[GormDocument loadFileWrapperRepresentation:ofType:] ( self=0x8544568, _cmd=0xb7dc22b8 _OBJC_SELECTOR_TABLE+696, wrapper=0x9082728, type=0x8143480) at GormDocument.m:3373 #5 0xb7a7782f in -[NSDocument readFromFileWrapper:ofType:error:] ( self=0x8544568, _cmd=0xb7dc22d0 _OBJC_SELECTOR_TABLE+720, wrapper=0x9082728, type=0x8143480, error=0xb53c) at NSDocument.m:723 #6 0xb7a77768 in -[NSDocument readFromURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc20b8 _OBJC_SELECTOR_TABLE+184, url=0x9082728, type=0x8143480, error=0xb53c) at NSDocument.m:757 #7 0xb7a78d41 in -[NSDocument initForURL:withContentsOfURL:ofType:error:] ( self=0x8544568, _cmd=0xb7dc2108 _OBJC_SELECTOR_TABLE+264, forUrl=0x99d4120, url=0x99d4120, type=0x8143480, error=0xb53c) at NSDocument.m:163 #8 0xb7a78bf5 in -[NSDocument initWithContentsOfURL:ofType:error:] ( self=0x8544568, _cmd=0xb7dc4800 _OBJC_SELECTOR_TABLE+384, url=0x99d4120, type=0x8143480, error=0xb53c) at NSDocument.m:189 #9 0xb7a7d222 in -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc48d8 _OBJC_SELECTOR_TABLE+600, url=0x99d4120, type=0x8143480, err=0xb53c) at NSDocumentController.m:446 #10 0xb7a7c76c in -[NSDocumentController openDocumentWithContentsOfURL:display:error:] (self=0x8831348, _cmd=0xb7e5a688 _OBJC_SELECTOR_TABLE+520, url=0x99d4120, flag=1 ' 01', err=0xb53c) at NSDocumentController.m:690 #11 0xb7ba748f in -[GSServicesManager application:openFile:] (self=0x81ca890, _cmd=0xb7e5a6b0 _OBJC_SELECTOR_TABLE+560, theApp=0x81f6ee8, file=0x811b3c8) at GSServicesManager.m:589 #12 0xb7ba7354 in -[GSServicesManager application:openFiles:] (self=0x81ca890, _cmd=0xb7d93128 _OBJC_SELECTOR_TABLE+1960, theApp=0x81f6ee8, files=0x816e008) at GSServicesManager.m:617 #13 0xb7a14c31 in -[NSApplication finishLaunching] (self=0x81f6ee8, _cmd=0xb7d93218 _OBJC_SELECTOR_TABLE+2200) at NSApplication.m:1126 #14 0xb7a1886d in -[NSApplication run] (self=0x81f6ee8, _cmd=0xb7d89408 _OBJC_SELECTOR_TABLE+904) at NSApplication.m:1538 #15 0xb79fa9bb in NSApplicationMain (argc=2, argv=0xb754) at Functions.m:91 #16 0x08049327 in main (argc=2, argv=0xb754) at main.m:30 ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]
Update of bug #42717 (project gnustep): Status:None = In Progress Assigned to:None = FredKiefer ___ Follow-up Comment #10: I now think that you did run into two independent issue, both being caused by a compiler that crashes when calling a method on nil that returns a structure type. It looks like gcc 4.9 has a new bug there and we need to prepare the whole GNUstep code for this. I tried to fix the two specific issues in the gui code, but if the above is true we are going to expect more problems. Pleas ebe patient with us and we may be able to squash all of them one by one. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42717 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]
Follow-up Comment #11, bug #42717 (project gnustep): No crash if I apply your changes in r38003. If it is a compiler bug, most probably it is present in earlier versions as this bug was reported last year when 4.9 was not released yet. However, it may be that GCC is taking advantage of the undefined behaviour scenario and is optimizing in a way that leads to a crash. Very often code that works with -O0 but fails with -O2 reveals a bug in the code, not the compiler. In any case, if it is a compiler bug, it should be haunted down and fixed rather than the code adapted to cope with it. IMHO. It might be difficult to write a self-contained example exposing the bug, though. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42717 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]
Follow-up Comment #12, bug #42717 (project gnustep): both being caused by a compiler that crashes when calling a method on nil that returns a structure type My understanding is that the behavior when calling a method expected to return a struct on a nil receiver is (and has always been) undefined. Certainly I know that it has always crashed on sparc machines. So I think it's a bit harsh to refer to a change in the undefined behavior as a new compiler bug I expect any code calling a method which returns a struct ought to check that the receiver is non-null fist. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42717 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42778] Frameworks with different SONAME cannot coexist
Follow-up Comment #1, bug #42778 (project gnustep): Actually, it is even more serious than that. Installing a new version of the framework will wipe out the old one completely, so there will only be one Version, with Current pointing to it. This is done unconditionally as the first command of the internal_framework_install_ recipe. The current behavior defeats the whole idea of frameworks (not that I ever understood what frameworks are for in the first place). What I wrote in the first message (that the old libBar is still in Versions/0) is true when the framework is packaged as it is installed in a tmp dir during build and there's no previous framework version to delete there. Steps to reproduce (with a random GNUstep framework): $ make $ make install DESTDIR=/tmp/foo $ make clean $ make install INTERFACE_VERSION=5 DESTDIR=/tmp/foo And the shocking result: $ ls -l /tmp/foo/usr/lib/ общо 20 drwxr-xr-x 3 yavor yavor 4096 юли 21 19:01 GNUstep lrwxrwxrwx 1 yavor yavor 67 юли 21 19:02 libRSSKit.so - ./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so lrwxrwxrwx 1 yavor yavor 69 юли 21 19:01 libRSSKit.so.0 - ./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.0 lrwxrwxrwx 1 yavor yavor 71 юли 21 19:02 libRSSKit.so.0.4 - ./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.0.4 lrwxrwxrwx 1 yavor yavor 69 юли 21 19:02 libRSSKit.so.5 - ./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.5 libRSSKit.so.0 is a broken symlink. As a result applications that linked with RSSKit cannot be started. $ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/ общо 4 drwxr-xr-x 4 yavor yavor 4096 юли 21 19:02 5 lrwxrwxrwx 1 yavor yavor1 юли 21 19:02 Current - 5 There should be a 0 directory there with the old library. Would you accept a patch that stops deleting the installed framework and also creates symlinks directly to Versions/$ver instead of Versions/Current? The .so symlink must probably still point to Current for projects linking with an internal framework to continue to work. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42778 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
