Thu 23 Oct 2014 05:59:27 AM UTC, comment #15:
Yes, this bug has been fixed.
|
Wed 22 Oct 2014 10:37:27 PM UTC, comment #14:
Yavor, can we consider this solved?
|
Wed 23 Jul 2014 07:57:27 AM UTC, 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.
|
Mon 21 Jul 2014 08:49:35 AM UTC, comment #12:
> 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.
|
Mon 21 Jul 2014 08:43:45 AM UTC, comment #11:
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.
|
Mon 21 Jul 2014 08:04:46 AM UTC, 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.
|
Sun 20 Jul 2014 03:30:47 PM UTC, comment #9:
Here's the valgrind output:
|
Sat 19 Jul 2014 03:47:24 PM UTC, comment #8:
Again, please try to run this code with valgrind. Se my comment on bug #42782.
|
Mon 14 Jul 2014 09:52:42 PM UTC, comment #7:
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 compressed output with pristine (unpatched) GNUstep GUI 0.24.0.
As for Valgrind, it used to be completely unusable for GNUstep IIRC. Haven't touched it for ages, so if any special setup is needed I'd appreciate if you give me some directions.
The Cenon version is 4.0.2; I see I missed mentioning that too.
(file #31715)
|
Mon 14 Jul 2014 09:27:13 PM UTC, comment #6:
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 it. If I remember correctly this was the time when I added the reading of the flattend properties, that is all the out of line changes in the XIB file.
It could well be that we handle one of these extra properties incorrectly.
Now it would be very helpful to know which of the 12 XIB files included in Cenon is causing the issue. To find that out it should be sufficient to start Cenon with the parameter --GNU-Debug=dflt
that should output the file it is currently loading.
With that information I could have a look at the XIB file to see if there is anything special.
You should also use --GNU-Debug=XIB to get more details about the XIB loading.
I really think that you are on to something and most likely it is in the XIB loading code, not just in the NSBox code. Although the code there in initWithCoder: could be improved a lot. It uses the calcSizesAllowingNegative: method way too often.
One other thing that you could try is to run Cenon with valgrind the memcheck setup. If you need help with that, I can provide it.
|
Mon 14 Jul 2014 06:16:58 PM UTC, comment #5:
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 I get a different crash:
(file #31714)
|
Mon 14 Jul 2014 01:11:04 PM UTC, comment #4:
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...
|
Thu 10 Jul 2014 04:26:20 PM UTC, comment #3:
When built with -O1, -calcSizesAllowingNegative: doesn't crash when called from -setBorderType: (aType there is 3 as expected) but from -setTitlePosition:
Corrupt stack again.
|
Thu 10 Jul 2014 09:42:35 AM UTC, comment #2:
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 back to -[GSXibKeyedUnarchiver decodeObjectForXib:forClassName:withID:], "o" is optimized on i386, while it is not on amd64. So I tried with gnustep-gui rebuilt with no optimization (-O0) and the problem doesn't happen -- Cenon starts and works. Hope that this gives you some clue.
It seems that -allocObjectForClassName: doesn't return a valid object and then it gets messy in -initWithCoder:. But I may be wrong here.
I'd appreciate any directions how to proceed further.
|
Wed 09 Jul 2014 09:31:55 PM UTC, comment #1:
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'
The flag should be a boolean and we only use YES or NO for it. This means something destroyed your stack and we need to find out what this was.
|
Wed 09 Jul 2014 01:48:17 PM UTC, original submission:
Cenon crashes on startup on a 32-bit system (cannot reproduce on amd64/x86_64):
GNUstep GUI 0.24.0, no themes installed.
|