CODEWITHSUNDEEP
c++multithreadingsegmentation-faultgdb
Min Lin
Min Lin

Reputation: 3197

How to trace the buggy code from this information

My project is quite large and multithreaded. There should be a bug which crashes the whole program.

For release version, it stuck sometimes, but does not appear very often. For debug code, it is more likely to appear. And the stack trace of gdb is the following.

0  clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:81
1  0x00007dff8270c700 in ?? ()
2  0x00007ffff6dde38d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

This information is not enough for me to locate the buggy code.

So my question is: how to get more information from the crash? any advanced use of gdb or other advanced tools?

============= Update ==============

One more information to add, after printing out all the thread ids, I figure out the thread that crashed. The only difference of the thread is that it is detached from the std thread object. If anyone has any experience with this, please tell me.

============= Update2 ================

This problem is not solved yet, and turn out to be a sever one. If I run in the terminal, it'll crash the whole terminal and all other programs currently running under my username. The system is then down and not accessible by ssh for a while. There are some other users getting broken pipe and it seems my program has made sshd not responsive.

After a while I'm able to login again, and find that the binary file of the program is broken (truncated) and need to recompile.

Upvotes: 1

Views: 126

Answers (1)

Klaus
Klaus

Reputation: 25593

For me it looks like a memory or stack overwrite or access of dead pointers or objects.

To catch these kind of errors I like to use tools like efence or valgrind. With actual compilers you also can use thread sanitizer or the memory sanitizer. Both works with clang and g++.

If you can not catch the problem with that, you also should install the debug library version of the standard libs. Sometimes a wrong value crashes inside the g++lib or some other libs which results in hard to debug situations. With the debug infos installed you can catch this much easier.

Upvotes: 2

Related Questions