https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87653
Bug ID: 87653
Summary: Calling null pointer in multi-threaded applications
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
CC: ian at gcc dot gnu.org
Target Milestone: ---
Created attachment 44856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44856&action=edit
C++ program to reproduce the issue
Using the same backtrace_state* from multiple threads is not safe.
Consider the attachment with a test program. Running it Segfaults. GDB shows
the following backtrace:
Thread 3 "a.out" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff674d700 (LWP 27705)]
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00000000004011d4 in source_line (addr=0x401180 <main_test_loop()>) at
thread_safety_checking.cpp:33
#2 main_test_loop () at thread_safety_checking.cpp:39
That happened because we jumped to address 0. It happened somewhere inside the
backtrace_pcinfo function:
0x00000000004011c2 <+66>: mov $0x401180,%esi
0x00000000004011c7 <+71>: movl $0x0,0x4(%rsp)
0x00000000004011cf <+79>: callq 0x401840 <backtrace_pcinfo>
=> 0x00000000004011d4 <+84>: mov 0x4(%rsp),%ebp
0x00000000004011d8 <+88>: test %ebp,%ebp
0x00000000004011da <+90>: je 0x40130f <main_test_loop()+399>
My assumption is that it happening at the `return state->fileline_fn (state,
pc, callback, error_callback, data);` line inside `backtrace_pcinfo`. Seems
that fileline_fn is a null pointer.
https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libbacktrace/fileline.c#L183
