[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]
Update of bug #42717 (project gnustep): Status: In Progress = Ready For Test Open/Closed:Open = In Test ___ Follow-up Comment #13: You are correct, calling this a compiler bug was incorrect. It is just changed behaviour in a corner case. The method in this case was supposed to return an NSSize value, that is two CGFloats and I think even on x86 this should be possible in registers, which are easlily set to zero. I still think it wasn't a great idea of the gcc people to change the optimisation in this case, but GNUstep code should take care to handle it correctly anayway, as we want to support Sparc and other platforms as well. What needs to be done now is to test as much of GNUstep code on x86 wiht gcc 4.9 as possible to avoid a massive issue when this compiler gets into more widespread use. ___ 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 #42782] Crash when loading a gorm file
Update of bug #42782 (project gnustep): Category: Gui/AppKit = Gorm Status:None = In Progress ___ Follow-up Comment #7: I am no expert on Gorm, but this looks very strange to me. If I understand the code in GormWrapperLoader loadFileWrapper:withDocument:] correctly this tries to load everything in the .gorm directory that looks like an image with GormImage. Now why would it try to load the data.info file as an image? Could you please print out the value of [NSImage imageFileTypes] and if this includes info try to find out where this comes from? I changed the category of this bug to Gorm to bring it to the attention of Gregory. We might need to change it back again when we find out more. ___ 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 #8, bug #42782 (project gnustep): Yes, the info type is there and the array is quite large: (gdb) po [NSImage imageFileTypes] (tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns, 3fr, a, aai, ai, art, arw, avi, avs, b, bgr, bgra, bie, bmp, bmp2, bmp3, brf, c, cal, cals, canvas, caption, cin, cip, clip, cmyk, cmyka, cr2, crw, cur, cut, dcm, dcr, dcx, dds, dfont, djvu, dng, dot, dpx, epdf, epi, eps, eps2, eps3, epsf, epsi, ept, ept2, ept3, erf, exr, fax, fits, fractal, fts, g, g3, gif87, gradient, gray, group4, hald, hdr, histogram, hrz, htm, html, icb, ico, icon, info, inline, ipl, isobrl, j2c, j2k, jbg, jbig, jng, jp2, jpc, jpx, k, k25, kdc, label, m, m2v, m4v, mac, map, mat, matte, mef, miff, mng, mono, mov, mp4, mpc, mpeg, mpg, mrw, msl, msvg, mtv, mvg, nef, nrw, null, o, orf, otb, otf, pal, palm, pam, pango, pattern, pbm, pcd, pcds, pcl, pct, pcx, pdb, pdf, pdfa, pef, pes, pfa, pfb, pfm, pgm, pgx, picon, pict, pix, pjpeg, plasma, png24, png32, png8, preview, ps, ps2, ps3, psb, psd, ptif, pwp, r, radial-gradient, raf, ras, rgb, rgba, rgbo, rla, rle, scr, sct, sfw, sgi, shtml, sr2, srf, stegano, sun, svg, svgz, text, tga, thumbnail, tiff64, tile, tim, ttc, ttf, txt, ubrl, uil, uyvy, vda, vicar, vid, viff, vst, wbmp, wmf, wmv, wmz, wpg, x, x3f, xbm, xc, xcf, xpm, xps, xv, xwd, y, ycbcr, ycbcra, yuv) Apparently these extra types come from GSImageMagickImageRep; I get them on amd64 too. ___ 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 #42782] Crash when loading a gorm file
Follow-up Comment #9, bug #42782 (project gnustep): FYI, the bug is reproducible if I rebuild GUI with --disable-imagemagick (the image file types are just tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns in that case). The gdb backtrace is meaningless again and the valgrind output is: ==8543== Command: Gorm ./English.lproj/Document.gorm/ ==8543== vex x86-IR: unhandled instruction bytes: 0x6D 0x7 0x8 0xC7 ==8543== Invalid write of size 1 ==8543==at 0xBEB7BF4A: ??? ==8543== Address 0x75b99204 is not stack'd, malloc'd or (recently) free'd ==8543== ==8543== ==8543== Process terminating with default action of signal 11 (SIGSEGV) ==8543== Access not within mapped region at address 0x75B99204 ==8543==at 0xBEB7BF4A: ??? ___ 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 #42782] Crash when loading a gorm file
Follow-up Comment #10, bug #42782 (project gnustep): I would expect that this new crash comes from a different place then before. The question is how we could find out where, given that gdb and valgrind don't give meaningful results. It would be great, if you had a bit more information. BTW, did you update Gorm to get the change I made there? ___ 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 #11, bug #42782 (project gnustep):
Yes, I used Gorm 1.2.20 + your latest changes. Most probably it is not an
issue with Gorm at all.
I'd really wish to provide more information... Perhaps I could put
breakpoints at some places and step through from there, this would at least
give you some clue, as blurry as that may be. As Gorm is a fairly complex
program, I'm trying Vindaloo first. I already figured out that Vindaloo
crashes in -[Document -makeWindowControllers], right after [self
addWindowController: ctrl]; ctrl is initalized properly with
-initWithWindowNibName: with [self windowNibName] as argument (which returns
@Document). Stepping from there:
(gdb) n
-[NSDocumentController openDocumentWithContentsOfURL:display:error:] (
self=0x840c0a8, _cmd=0xb7f73648 _OBJC_SELECTOR_TABLE+520, url=0x840ae20,
flag=1 ' 01', err=0xb4cc) at NSDocumentController.m:708
708 [self noteNewRecentDocument: document];
(gdb) n
710 if (flag [self shouldCreateUI])
(gdb) n
712 [document showWindows];
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
Putting breakpoints further:
Breakpoint 2, -[NSDocument showWindows] (self=0x82a1268,
_cmd=0xb7edd828 _OBJC_SELECTOR_TABLE+488) at NSDocument.m:415
415 {
(gdb) po _window_controllers
(Controller: 0x83e54f8)
(gdb) n
417 withObject: self];
(gdb) n
416 [_window_controllers makeObjectsPerformSelector:
@selector(showWindow:)
(gdb) n
417 withObject: self];
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
Breakpoint 3, -[NSWindowController showWindow:] (
self=0xb7edb1b8 _OBJC_SELECTOR_TABLE+504,
_cmd=0xb7edb1b8 _OBJC_SELECTOR_TABLE+504, sender=0x81fdb90)
at NSWindowController.m:394
394 {
(gdb) n
395 NSWindow *window = [self window];
(gdb) po self
Controller: 0x83e73e8
(gdb) po [self window]
Program received signal SIGSEGV, Segmentation fault.
0xbfffef6a in ?? ()
Breakpoint 4, -[NSWindowController window] (self=0x83ea168,
_cmd=0xb7f680f0 _OBJC_SELECTOR_TABLE+176) at NSWindowController.m:297
297 {
(gdb) n
298 if (_window == nil ![self isWindowLoaded])
(gdb) n
308 [self windowWillLoad];
(gdb) p _window
$5 = (struct NSWindow *) 0x0
(gdb) n
309 if (_owner != self
(gdb) po self
Controller: 0x83ea168
(gdb) po _owner
Controller: 0x83ea168
(gdb) n
315 [self loadWindow];
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
Breakpoint 5, -[NSWindowController loadWindow] (self=0x83e5340,
_cmd=0xb7f68170 _OBJC_SELECTOR_TABLE+304) at NSWindowController.m:476
476 {
(gdb) n
479 if ([self isWindowLoaded])
(gdb) n
484 table = [NSDictionary dictionaryWithObject: _owner forKey:
NSNibOwner];
(gdb) po table
value has been optimized out
(gdb) n
485 if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) po self
Controller: 0x83e5340
(gdb) po [self windowNibPath]
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po _owner
Controller: 0x83e5340
(gdb) n
487 withZone: [_owner zone]])
(gdb) n
485 if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) n
487 withZone: [_owner zone]])
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
Breakpoint 6, +[NSBundle(NSBundleAdditions)
loadNibFile:externalNameTable:withZone:] (self=0xb79d43e0
_OBJC_Class_NSBundle,
_cmd=0xb7f68250 _OBJC_SELECTOR_TABLE+528, fileName=0x8268c18,
context=0x8267fe0, zone=0xb7a3f0c0 default_zone)
at NSBundleAdditions.m:234
234 {
(gdb) n
235 NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) po fileName
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po [NSURL fileURLWithPath: fileName]
file://localhost/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm/
(gdb) po context
{NSOwner = Controller: 0x83e5568; }
(gdb) n
237 withZone: zone];
(gdb) po nib
value has been optimized out
(gdb) n
235 NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) n
239 RELEASE(nib);
(gdb) n
235 NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) n
237 withZone: zone];
(gdb) n
236 BOOL loaded = [nib instantiateNibWithExternalNameTable: context
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
Breakpoint 7, -[NSNib instantiateNibWithExternalNameTable:withZone:] (
self=0x8411090, _cmd=0xb7ebc0d0 _OBJC_SELECTOR_TABLE+208,
externalNameTable=0x8410c28, zone=0xb7a3f0c0 default_zone) at
NSNib.m:152
152
