Search code examples
c++qtcrashgdb

C++/Qt application exits without any inidication

Well, I am writing a small application using C++, Qt and some libraries. Some computation is executed when hitting a UI button.

Now I found that after around one minute the application exits reproducibly and reliably without any visible reason. The error seems not happen statistically but deterministically. I guess there is some bug triggering the crash but I can not find any hint where/why this is happening.

Honestly I have never seen such a crash during the last decade, normally I get even a small indication what happened.

I am using GCC 11.3, GDB, Qt Creator on Kubuntu 22.10 Linux. I built a debug executeable and run it. This is what I checked:

  • Run using debugger, Qt creator console says "...app has finished with exit code 0."
  • Run without debugger, Qt creator console says "...app crashed."
  • Run on bash it only says "Getötet" (which is german and means "killed")
  • No error related application console output or dialogs are generated
  • Logging component (which logs all signals, intercept-able C++ exit calls, Qt output and more) does not log anything unexpected
  • Application does not exit by main()-return (debugger break-point is not triggered and corresponding log trace isn't generated)
  • No signal dialog (like SIGTERM and SIGABRT) is shown
  • No assertion seems to be triggered (would generate output and would halt the debugger)
  • I enabled break-on-abort but nothing happens
  • I enabled break-on-C++-exception but nothing happens
  • I searched my code for exit calls (especially with a return code of 0) but there is no such call.

After all I have no idea how to debug the issue other than cluttering my entire application with debug messages and check for missing prints.

Any idea what could happening here and why I don't get even the slightest indication for the error reason? Is there a way to track down the issue using GDB?

Solution

  • Ok, solution was pretty easy. It wasn't any leak or memory error. Also it wasn't an exit call of any kind.

    Reason was basically an internal buffer that could grow beyond the size of physically installed memory under some circumstances. That triggered the OS' OOM-Killer process.

    Problem didn't produce any immediate error indication but it could have been tracked down by monitoring system resources and by checking the kernel log (that contained corresponding "oom-kill" and "oom_reaper" messages).