1

I'm using the PellesC C compiler. Sometimes my code randomly stops working. A particular statement can trigger it. For example, I multiplied a variable by sin(c) (c is a double) and my code seemed to just finish execution with no result. Sometimes it freezes, sometimes it appears to just return, but I can always fix it by removing the offending statement or disabling compiler optimizations, specifically "maximize speed" or "maximize speed more". The freezing will also go away nearly 100% of the time if I add a printf statement somewhere near the point at which it crashes. I've never found anything to suggest that I am accessing memory improperly, I'm fairly sure its a compiler issue. I was wondering if anybody could shed some light on this. Is it possible that I am, in fact, doing something wrong? Or is this a known issue with the Pelles C compiler?

Edit:

Changing

canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+2]=(unsigned char)(255.0*dtempA*(1-sin(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+1]=(unsigned char)(255.0*dtempA*(1+cos(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)]=(unsigned char)(255.0*dtempA*(1+sin(c)));

to (difference at the end of the last line)

canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+2]=(unsigned char)(255.0*dtempA*(1-sin(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)+1]=(unsigned char)(255.0*dtempA*(1+cos(c)));
canvas->pixels[(y*canvas->pitch)+(x*canvas->Bpp)]=(unsigned char)(255.0*dtempA*(1+1));

makes it work.

Void Star
  • 2,401
  • 4
  • 32
  • 57
  • 3
    Do you have a testcase to show? – ouah Jul 11 '12 at 22:57
  • 1
    Yes, it is possible that you are doing something wrong, like rely on constructs that cause undefined behavior. That's about all that can be said without an [SSCCE](http://sscce.org/). – Fred Foo Jul 11 '12 at 23:00
  • Are you handling SIGFPE? – user207421 Jul 11 '12 at 23:41
  • Unfortunately the program I am working on right now is around 750 lines of code and showing you a small piece of the code would likely defeat the error so an SSCCE isn't possible, part of the reason I am having such a hard time understanding these glitches. I am 100% positive that the arithmetic is not the issue and this issue has been caused by lines of code without any such operations in the past. – Void Star Jul 12 '12 at 00:35
  • 2
    @BigEndian: An SSCCE **is** possible, you'd just have to work at it. I would wager you any amount you like that you don't need all 750 lines to reproduce the problem. – Oliver Charlesworth Jul 12 '12 at 00:40
  • But if I don't understand what the problem is and it randomly disappears... it might be a little difficult. I'll give it a go. – Void Star Jul 12 '12 at 00:42
  • @BigEndian: Yup, that's what debugging is! – Oliver Charlesworth Jul 12 '12 at 00:44
  • I added a very small code sample. You can't reproduce the problem with this but it shows you exactly what I'm talking about. Why would removing a sin(c) like this make it work??? – Void Star Jul 12 '12 at 00:49
  • Is it possible that the compiler is completely skipping lines of code? Because the program appears to be running to the end and the values it says it is plotting are correct, but either the pixels aren't getting set or the program isn't saving the image (I wrote a header which saves pixel arrays as .bmp files). – Void Star Jul 12 '12 at 00:57

2 Answers2

4

It could be either but a good bet is that it's you :) Variables that are not explicitly initialized will often get different values in a optimized vs an un-optimized build because the stack layout can change subtly depending on how aggressively the compiler removes temporaries, as well as other factors.

500 - Internal Server Error
  • 28,327
  • 8
  • 59
  • 66
  • I will check all of my variables. I try to be very careful about that. – Void Star Jul 12 '12 at 00:29
  • I will say this, I just noticed that every single project I have encountered this issue with deals with 3D graphics. I have a ~400 line header I wrote that deals with vectors and matrices. So I use a lot of arrays of 3 or 16 doubles. However, I am very careful to initialize them as an array or a pointer then allocate the memory I need. No matrix or vectors is used before being given a value that I can see. – Void Star Jul 12 '12 at 00:38
2

You're probably accidentally using undefined behavior somewhere, and changing random instructions in the program is breaking the very fragile alignment of the code on the stack that happens to make the program work.

argentage
  • 2,758
  • 1
  • 19
  • 28
  • Wait wait... Code on the stack? I thought that C only used the stack for storing variables, passing arguments, returning values, etc. And for further clarification, are you saying that my program is accidentally changing bytes in the memory used for executable code? Would the memory allocated for the stack be physically close enough to the executable code for that to happen in any reasonably realistic scenario? – Void Star Jul 12 '12 at 23:54
  • Sorry, I was being really imprecise. It probably changed the memory values of things on the stack and so the program instructions which referred to those memory values (IE, relative references to the stack pointer and stuff) were probably altered. You're correct in that actual code isn't stored on the stack, nor is that data itsself changed - but rather that small changes to programs with UB can suddenly give the compiler the ability to do radically different things. – argentage Jul 13 '12 at 04:14