Closed surfacepatterns closed 4 weeks ago
I've attached code that reproduces the crash to this issue. You can compile the program using:
g++ -o repro repro.cpp -O0 -DNDEBUG $(pkg-config absl_synchronization --cflags --libs)
Running the compiled program using gdb
yields the following:
danderson [ ~/projects/abseil-cpp-repro ]$ gdb ./repro
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./repro...
(No debugging symbols found in ./repro)
(gdb) run
Starting program: /home/danderson/projects/abseil-cpp-repro/repro
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/printers.py:1273: SyntaxWarning: invalid escape sequence '\d'
self.typename = re.sub('^std::experimental::fundamentals_v\d::', 'std::experimental::', self.typename, 1)
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/printers.py:1302: SyntaxWarning: invalid escape sequence '\w'
x = re.sub("std::string(?!\w)", s, m.group(1))
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/printers.py:1346: SyntaxWarning: invalid escape sequence '\d'
self.typename = re.sub('^std::(experimental::|)(fundamentals_v\d::|)(.*)', r'std::\1\3<%s>' % valtype, typename, 1)
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:151: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?array<.*>$', class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:268: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?deque<.*>$', class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:312: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?forward_list<.*>$', class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:393: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?(__cxx11::)?list<.*>$', class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:508: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?vector<.*>$', class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:557: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?%s<.*>$' % self._name, class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:590: SyntaxWarning: invalid escape sequence '\d'
if re.match('^std::(__\d+::)?__uniq_ptr_(data|impl)<.*>$', impl_type):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:592: SyntaxWarning: invalid escape sequence '\d'
elif re.match('^std::(__\d+::)?tuple<.*>$', impl_type):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:654: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?unique_ptr<.*>$', class_type.tag):
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:723: SyntaxWarning: invalid escape sequence '\['
m = re.match('.*\[(\d+)]$', str(self._elem_type))
/usr/lib/../share/gcc-13.2.0/python/libstdcxx/v6/xmethods.py:775: SyntaxWarning: invalid escape sequence '\d'
if not re.match('^std::(__\d+::)?shared_ptr<.*>$', class_type.tag):
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
iteration 0
initializing mutex
locking mutex
destroying mutex
iteration 1
initializing mutex
locking mutex
[mutex.cc : 1418] RAW: Potential Mutex deadlock:
[mutex.cc : 1428] RAW: Acquiring absl::Mutex 0x7fffffffdb60 while holding 0x7fffffffdb60; a cycle in the historical lock ordering graph has been observed
[mutex.cc : 1432] RAW: Cycle:
[mutex.cc : 1446] RAW: mutex@0x7fffffffdb60 stack:
[mutex.cc : 1454] RAW: dying due to potential deadlock
Program received signal SIGABRT, Aborted.
0x00007ffff79960d4 in __pthread_kill_implementation () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff79960d4 in __pthread_kill_implementation () from /usr/lib/libc.so.6
#1 0x00007ffff7945bde in raise () from /usr/lib/libc.so.6
#2 0x00007ffff792e832 in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7f17527 in absl::lts_20240116::raw_log_internal::(anonymous namespace)::RawLogVA(absl::lts_20240116::LogSeverity, char const*, int, char const*, __va_list_tag*) () from /usr/lib/libabsl_raw_logging_internal.so.2401.0.0
#4 0x00007ffff7f175be in absl::lts_20240116::raw_log_internal::RawLog(absl::lts_20240116::LogSeverity, char const*, int, char const*, ...) ()
from /usr/lib/libabsl_raw_logging_internal.so.2401.0.0
#5 0x00007ffff7fb21a0 in absl::lts_20240116::DeadlockCheck(absl::lts_20240116::Mutex*) () from /usr/lib/libabsl_synchronization.so.2401.0.0
#6 0x00007ffff7fb4ab5 in absl::lts_20240116::Mutex::Lock() () from /usr/lib/libabsl_synchronization.so.2401.0.0
#7 0x0000555555555255 in main ()
It looks like this was resolved by #10003; thanks for reporting this issue and contributing a fix!
Describe the bug The current
abseil-cpp
package is built withCMAKE_BUILD_TYPE
set toNone
. This results in the package being built withoutNDEBUG
being defined. This creates ABI incompatibilities betweenabseil-cpp
and packages that depend onabseil-cpp
that are compiled withNDEBUG
defined.I came across this issue when I was running tests for a custom
grpc
based service against Azure Linux. Each time I would run tests, the test executable would end up crashing withgdb
tracebacks similar to this (sans traceback entries into proprietary code):This happened because the implementation of
absl::Mutex
is changed by the presence of anNDEBUG
definition. Whenabseil-cpp
is compiled withoutNDEBUG
, this definition ofabsl::Mutex::Dtor()
is defined in the shared library and meant to be called by theabsl::Mutex
destructor. This helps clear out deadlock info whenNDEBUG
isn't defined. However, whenNDEBUG
is defined by dependent packages, this definition ofabsl::Mutex::Dtor()
is inlined in the dependent binary for use by the dependent package, resulting in the former definition being unused, and causinggrpc
and other dependent packages to abort sporadically (but often) atabsl::Mutex
entry points.One of the prominent maintainers of
abseil-cpp
has mentioned this issue previously.This pull request fixes the problem.
To Reproduce Steps to reproduce the behavior:
abseil-cpp
, preferably something that creates and destroysabsl::Mutex
instances, and make sure to defineNDEBUG
when compiling.(If the above doesn't illustrate the problem well enough, then I'll attempt to supply a minimal reproduction of the bug when I get a chance.)
Expected behavior I expect applications that link to
abseil-cpp
to run without crashing.