-3

as the title mentions, I have a problem where one executable of a big project that gives a segmentation fault when it runs but is compiled normally and not with debug.

We are working on linux SUSE servers and code is mostly C++. Through bt in gdb, I have been able to see where exactly the problem occurs, which brings me to the question. The file is an auto-generated one which has not been changed for years. The difference now is that we have updated a third party component, gSOAP. Before updating the third party version it worked normally on both debug and not.

With debug flags, the problem disappears magically (for newbies like me). I am sorry but its not possible to include a lot of code, only the line that is:

/*------------------------------------------------------------.
| yynewstate -- Push a new state, which is found in yystate.  |
`------------------------------------------------------------*/
 yynewstate:
  /* In all cases, when you get here, the value and location stacks
     have just been pushed.  So pushing a state here evens the stacks.  */
  yyssp++;

 yysetstate:
  *yyssp = yystate; <------------------ THIS LINE

So, any help would appreciated. I actually dont understand why this problem rises and what steps I should take to solve it.

EDIT, I dont expect you to solve this particular case for me, as in more to help me understand why in programming this could occur, my case in this code is just an example.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
thahgr
  • 718
  • 1
  • 10
  • 27
  • 1
    We don't know what `yyssp` is pointing to, or how large a buffer it roams over -- if it's been initialized at all. There's just no way to tell what's going on from this little code. – Paul Roub Feb 27 '15 at 16:25
  • @Paul I mention that I cant include more code, the question is more of general one, how can a program run fine when compiled in debug mode and not run when compiled normally. of course you cant figure out from this code, I want to understand the forest, not the tree.. – thahgr Feb 27 '15 at 16:28
  • 1
    And there are an unending number of reasons that might happen. We can start randomly imagining some of them, but that won't help. Every thing from `#ifdef DEBUG` blocks, to compilers initializing variables for debugging that aren't initialized in optimized builds, to different debug/release libraries, to... – Paul Roub Feb 27 '15 at 16:30
  • Perhaps you use incorrect pointer anywhere. This can give various errors depending on the compilation settings. Especially when you use uninitialized pointer and write data in a random place in memory. – Piotr Siupa Feb 27 '15 at 16:40
  • @NO_NAME, thanks for your idea, but the file is auto-generated and has never been changed. the only thing that changed is the third party software where we link some libraries... does this help somehow? – thahgr Feb 27 '15 at 16:42
  • 1
    @thahgr We have even less information than you do, since you have the full trace and we don't, you know what the program does and we don't, you know if the program is multi-threaded and we don't, you know if the problem is sporadic or predictable and we don't, you have access to the full code and we don't. – David Schwartz Feb 27 '15 at 16:59
  • 1
    @thahgr I think you should find someone on your end who is more experienced in C++ to help you. This may be an easy problem to fix, but it could also be very subtle as to what the issue is, so much so that only an experienced person can identify the problem. – PaulMcKenzie Feb 27 '15 at 17:07

2 Answers2

4

First, please realize that you're using C++, not Java or any other language where the running of your program is always predictable, even runtime issues are predictable.

In C++, things are not predictable as in those languages. Just because your original program hasn't changed for years does not mean the program was error-free. That's how C++ works -- you think you have an error-free program, and it is not really error-free.

From your code, the exception is because yyssp is pointing to something it shouldn't be pointing to, and dereferencing this pointer causes the exception. That is the only thing that could be concluded from the code you posted. Why the pointer is pointing to where it is? We don't know, that is what you need to discover by debugging.

As to why things run differently in debug and release -- again, a bug like this allows a program to run in an unpredictable way. Add or remove code, run it on another machine, run it with differing compiler options, maybe even run it next week, and it might behave differently.

One thing you should not do -- if you make a totally irrelevant code change and magically your program works, do not claim the problem is fixed or resolved. No -- the problem is not fixed -- you've either masked it, or the bug is moved to another part of your code, hidden from you. Every fix that entails things like this must be reasoned as to why the fix addresses the problem.

Too many times, a naive programmer thinks that moving things around, adding or removing lines, and bingo, things work, that becomes the fix. Don't fall into that trap.

PaulMcKenzie
  • 34,698
  • 4
  • 24
  • 45
  • Java programs are not always predictable. Threads would be an obvious example for unpredictable behaviour, but any dependency on external resources can cause this; think of file systems or network connections. And let's not forget native methods and finalizers. The point is that just because someone is used to Java, one should not assume that this person does not understand non-deterministic program execution. – Christian Hackl Feb 27 '15 at 16:54
  • 1
    Yes, threads and external things occurring are one thing. What I'm referring to is undefined behavior is inherent in the C++ language. It isn't that way with Java. Undefined behavior, as part of the language spec, is not found in too many other languages besides C and C++. – PaulMcKenzie Feb 27 '15 at 16:56
  • @PaulMcKenzie, thanks for taking the time to write a broad answer, you have been helpful – thahgr Mar 02 '15 at 07:12
  • This is an excellent answer. It's a shame the OP didn't see fit to accept it, choosing their own instead. – Lightness Races in Orbit Mar 03 '15 at 11:31
-3

someone in my team found a temporary solution for this, it was the optimization flags that this library is build with.
The default for our build was -O2 while on debug this changes.

Building the library with -O0 (changing the makefile) provides a temporary solution.

thahgr
  • 718
  • 1
  • 10
  • 27
  • That is not a "solution", temporary or otherwise. Your code is _broken_ and could still break at any moment. In fact you haven't even pretended to solve the problem of "the code breaks in release builds", because all you're doing now is _not making release builds_. The person in your team should be given a stern talking to... – Lightness Races in Orbit Mar 03 '15 at 11:32
  • Sorry, but that is not a fix. Did you read my answer carefully, concerning making irrelevant changes to the code (either the generated code or the source code) and things start to "work"? The code is not working -- all you did was rearrange the code so now the bug has moved somewhere else. – PaulMcKenzie Mar 03 '15 at 15:38