[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Update of bug #42717 (project gnustep): Status: Ready For Test => Fixed Open/Closed: In Test => Closed ___ Reply to this item at:

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #15, bug #42717 (project gnustep): Yes, this bug has been fixed. ___ Reply to this item at: ___ Message sent via/by Savannah http://

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #14, bug #42717 (project gnustep): Yavor, can we consider this solved? ___ Reply to this item at: ___ Message sent via/by Savannah h

[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, c

[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) undef

[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 "unde

[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 y

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #9, bug #42717 (project gnustep): Here's the valgrind output: $ valgrind Cenon ==14425== Memcheck, a memory error detector ==14425== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==14425== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==1442

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #8, bug #42717 (project gnustep): Again, please try to run this code with valgrind. Se my comment on bug #42782. ___ Reply to this item at:

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #7, bug #42717 (project gnustep): I was sure I mentioned it was the Main.xib file, but apparently missed that. Sorry. I tried --GNU-Debug=XIB as soon as I found out the crash happens when loading the XIB file, but was completely lost in the data it spits. Attached is the compr

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #6, bug #42717 (project gnustep): Thank you for finding the commit that caused this problem. If you look at the files included in that commit you will find that it also includes a lot of other changes that actually result in the XIB file being loaded completely not just parts of

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #5, bug #42717 (project gnustep): Moving the NSTitleCell decoding at the beginning as in the attached patch makes Cenon load with 0.24.0. -calcSizesAllowingNegative: accesses _cell so at first glance it looks like the correct change. However, if I apply the patch against trunk

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #4, bug #42717 (project gnustep): As I ran out of ideas I made a binary search. The "bad" commit is r34050. It's not easy for me to spot what's wrong, though... ___ Reply to this item at:

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #3, bug #42717 (project gnustep): When built with -O1, -calcSizesAllowingNegative: doesn't crash when called from -setBorderType: (aType there is 3 as expected) but from -setTitlePosition: Breakpoint 1, -[NSBox setTitlePosition:] (self=0x921f6b0, _cmd=0xb7edb618 <_OBJC_SEL

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #2, bug #42717 (project gnustep): Yep, I noticed that dubious aFlag too. It looks like it is exactly the same problem that was reported in 2013. If I put a break on -[NSBox setBorderType:], aType is garbage (10-digit number) instead of the expected value of 3. Going further ba

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #1, bug #42717 (project gnustep): Looks very similar to the problem that was reported by German Arias on the GNUstep mailing list in January 2013. At that time I could not reproduce it on my 64 bit machine. There is one bit in your stack dump that looks suspicious: aFlag=88 'X'

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

URL: Summary: Crash in -[NSBox(Private) calcSizesAllowingNegative:] Project: GNUstep Submitted by: yavor Submitted on: Wed 09 Jul 2014 04:48:17 PM EEST Category: Gui/AppKit