VTK exe crash in Ubuntu, no core dump, no crash log, no VTK output window…what tools or cmd is popular when dev on Ubuntu?
must build Debug lib of VTK to enable the things above?
is it able to build Debug and Release at the same time?
alread ‘ulimit -c unlimited’, but when ‘./test’ there is still no core dump…
when ‘gdb test’, ‘run’, there is :‘Inferior 1(process xxx) exit normally’, no VTK output window or any other log…but after ‘run’ ‘import register_libstdcxx_printers’'ModuleNotFoundError: No module named ‘libstdcxx’
Assuming you have the GNU devtoolset, yes, gdb is the primary choice. However gdb is a bit difficult to use. I think you’re better off by using some graphical front end to gdb like KDbg or Qt Creator (it has a nice gdp front end that can attach to any process, in case you’re not developing a Qt program). Alternatively, the Valgrind set of debugging/profiling tools is more powerful and comes with a GUI front end.
Yes, to catch crashes inside VTK, you need to build VTK in debug mode.
Yes. Just use two build directories: one for release, one for debug. Also, set two different install prefixes (install paths) for each.
AFAIK, Release builds will catch them, just have ?? in place of a lot of information in the backtrace (possibly to the point of uselessness). I recommend RelWithDebinfo to get the most useful kinds of optimizations applied at least.
I had problems with RelWithDebugInfo before such as incorrect line-by-line execution and variable inspection. I’d recommend that mode only if you do need it, for example, you need to diagnose an issue triggered only by some large data set.
There are two debug build modes because none of them is perfect and you need to choose between them depending on what exactly you need.
Using debug mode may be inconvenient because VTK may be 10x slower (no inline methods, on Windows there are lots of extra checks in standard containers, etc) and some errors (e.g., uninitialized memory area, performance and concurrency related problems) may not be reproducible in debug mode.
Using RelWithDebInfo can be confusing because inline functions (and functions that are auto-inlined at build time) are removed, variables may be removed (replaced by registers), order of instruction execution may be changed. When you run code in this mode then it is normal that the debugger randomly skips lines, jumps around, and you cannot inspect some variables (if you really want to know what code is executed then you need to switch to assembly view, but interpreting that code requires a whole new skill set).