Random crashes with "Process returned -1 (0xFFFFFFFF)"

[maeriden]

I randomly get this when I execute my program. Sometimes it happens three times in a row sometimes it can go about 10 times before it shows up again.
I was not able to find out what the error code means, and I can't pinpoint the error. During debugging it NEVER happens, and logging tells me it happens between two cout << operations. I'm guessing I screwed up something with threads.

Does anyone have any idea of what the error code means?

[kbw]

You haven't given us much to go on. But you need to debug the process. What OS are you on?

[andywestken]

Also, if you're using an IDE (or debugger?), which one is it?

Andy

[maeriden]

Arch Linux 64bit, Code::Blocks 12.11 with GDB.

But ike I said, during debugging the problem didn't pop up even once.

[kbw]

Run the app in GDB. When it aborts, do a back trace (bt) to dump the stack. That'll at least show the call stack.

GCC does so much to your code when optimisation is turned on. You just have to narrow it down one step at a time.

[andywestken]

Out of interest, is it possible to set up GDB on Linux as a Just In Time (JIT) debugger?

(Note that here JIT refers to the debugger, not to what it's debugging.)

My experience with this kind of problem is with Windows -- those problematic cases where the bug never, ever occurs when running the app under the debugger, due to memory alignment differences or whatever. So I run the repro scenario as normal but with the JIT debugger configured. Then, when the app crashes, the debugger is automatically launched and attached to the process so I can see what's happened (hopefully!)

Andy

PS A quick Google later...

If these threads read like I think they do, this means you have to compile a signal handler into you app to achieve the same effect. Is that true? Or is there a more generic way to trigger a debugger to launch and attach to a process when it crashes on Linux?

Waiting with a crash for a debugger?
http://stackoverflow.com/questions/1465336/waiting-with-a-crash-for-a-debugger

Re: Just-in-time debugging on Linux - msg#00069
http://osdir.com/ml/gdb.devel/2002-06/msg00069.html

Also, how to set up WinDbg on Windows for post mortem (aka JIT) debugging, so you know what I'm talking about?

Enabling Postmortem Debugging
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542967%28v=vs.85%29.aspx

[maeriden]

I tried running GDB from the terminal about 40 times and it never crashed. As for optimization, I don't use any -O switch, though I don't know how much the code gets optimized by default.

Out of interest, is it possible to set up GDB on Linux as a Just In Time (JIT) debugger?

I never even heard of this. I'll try to read up on the topic and see if I can manage something.

[maeriden]

I copied the code from the second link into my project and it works.
This is the result

Using configuration file res/defaults.cfg
Resolution = 800x600
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
---- bunch of my own logging omitted, below is the last executed ----
al::Source::Attach(string)... Done

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
---- Copyright plus a lot of symbol loading omitted ----
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff7c1fe000
0x00007f482d09ab9d in nanosleep () from /usr/lib/libc.so.6
(gdb)  bt
#0  0x00007f482d09ab9d in nanosleep () from /usr/lib/libc.so.6
#1  0x00007f482d09aa34 in sleep () from /usr/lib/libc.so.6
#2  0x00000000004121ff in crash_handler (sig=11)
    at /home/dan/dev/mge/src/main.cpp:36
#3  <signal handler called>
#4  0x00007f482d95e893 in std::string::swap(std::string&) ()
   from /usr/lib/libstdc++.so.6
#5  0x00007f482d95e8d9 in std::string::operator=(std::string&&) ()
   from /usr/lib/libstdc++.so.6
#6  0x000000000040e53b in GameState::DecryptScript (this=0x1a57360, 
    filePath="res/script.txt", encrypted=true)
    at /home/dan/dev/mge/src/gamestate.cpp:188
#7  0x000000000040ed24 in GameState::LoadScript (this=0x1a57360, 
    file="res/script.txt") at /home/dan/dev/mge/src/gamestate.h:62
#8  0x000000000040d7aa in GameState::GameState (this=0x1a57360, 
    manager=0x1a49640, file="script.txt")
    at /home/dan/dev/mge/src/gamestate.cpp:38
#9  0x000000000040af79 in Game::Game (this=0x1a49640)
    at /home/dan/dev/mge/src/game.cpp:46
#10 0x0000000000412301 in main (argc=1, argv=0x7fff7c18ff08)
    at /home/dan/dev/mge/src/main.cpp:73

The log wasn't showing up correctly because I didn't flush the stream before the crash. After fixing this, I think I pinpointed the problem: I have an std::list<Token> in which I read chunks of the script, and then assign the token strings to other variables. Logging shows that occasionally there are more tokens than there should be with weird values, and I'm guessing assigning them causes the crash. Now I'm looking into possible reading errors of the file.

Thanks a lot Andy.

[maeriden]

After 20 executions seems like it's ok now. Instead of using EOF to stop parsing the input I pass the size of the file and I haven't had problems so far.

[ne555]

You may also loop against the reading operation while( std::getline(std::cin, line) )

[maeriden]

The input is stored in a char array.

[ne555]

while( std::cin.getline(line, size) ) then

[maeriden]

I may have phrased that wrong, I mean the input is already in a char array and i loop through that.