Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASSERT synch.c:261 on client.destructor test on ubuntu22 32-bit #6541

Open
derekbruening opened this issue Jan 5, 2024 · 0 comments
Open

Comments

@derekbruening
Copy link
Contributor

I tried to reproduce the synch.c:261 assert on the drcachesim tests on GA
CI ubuntu22 32-bit seen in PR #6534 on a local machine and failed. But on
running the whole suite there I did hit the assert in the client.destructor
test.

Running under gdb, first we have SIGSEGV in privlib constructor:

Program received signal SIGSEGV, Segmentation fault.
0xf724fbed in ?? ()
(gdb) x/3i 0xf724fbed 
   0xf724fbed:	mov    %gs:0x4fe,%al
   0xf724fbf3:	movzbl %al,%eax
(gdb) bt
#0  0xf724fbed in ?? ()
#1  0xf72d649d in write ()
#2  0xf733dd65 in _IO_file_write ()
#3  0xf733d5a6 in ?? ()
#4  0xf733df15 in _IO_file_xsputn ()
#5  0xf723f904 in fwrite ()
#6  0xf78c5b49 in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::xsputn(char const*, int) ()
#7  0xf78f2df2 in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int) ()
#8  0xf78f3192 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) ()
#9  0xf7fba274 in hasdtr::hasdtr (this=0xf7fbd00f) at /home/derek/dr/git/src/suite/tests/client-interface/destructor.dll.cpp:46
#10 0xf7fba1ff in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/derek/dr/git/src/suite/tests/client-interface/destructor.dll.cpp:54
#11 0xf7fba247 in _GLOBAL__sub_I_destructor.dll.cpp(void) () at /home/derek/dr/git/src/suite/tests/client-interface/destructor.dll.cpp:60
#12 0xf7c8370a in privload_call_lib_func (func=0xf7fba228 <_GLOBAL__sub_I_destructor.dll.cpp(void)>) at /home/derek/dr/git/src/core/unix/loader.c:1079
#13 0xf7c8231b in privload_call_entry (dcontext=0x4075fb40, privmod=0x407584f8, reason=1) at /home/derek/dr/git/src/core/unix/loader.c:629
#14 0xf7b89823 in privload_call_entry_if_not_yet (dcontext=0x4075fb40, privmod=0x407584f8, reason=1) at /home/derek/dr/git/src/core/loader_shared.c:121
#15 0xf7b8b832 in privload_load_finalize (dcontext=0x4075fb40, privmod=0x407584f8) at /home/derek/dr/git/src/core/loader_shared.c:829
#16 0xf7b89baa in loader_init_epilogue (dcontext=0x4075fb40) at /home/derek/dr/git/src/core/loader_shared.c:217
#17 0xf7a3052f in dynamorio_app_init_part_two_finalize () at /home/derek/dr/git/src/core/dynamo.c:675
#18 0xf7c85b98 in privload_early_inject (sp=0xffffd4e0, old_libdr_base=0x0, old_libdr_size=0) at /home/derek/dr/git/src/core/unix/loader.c:2259
#19 0xf7c39a39 in reloaded_xfer () at /home/derek/dr/git/src/core/arch/x86/x86.asm:1187
#+end_example
Then we have a 2nd SIGSEGV processing the first:
#+begin_example
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xf7b554c1 in check_in_last_thread_vm_area (dcontext=0x4075fb40, pc=0x4fe <error: Cannot access memory at address 0x4fe>) at /home/derek/dr/git/src/core/vmareas.c:8398
8398	        if (is_readable_without_exception((app_pc)&shared_data->last_area->end, 4) &&
(gdb) bt
#0  0xf7b554c1 in check_in_last_thread_vm_area (dcontext=0x4075fb40, pc=0x4fe <error: Cannot access memory at address 0x4fe>) at /home/derek/dr/git/src/core/vmareas.c:8398
#1  0xf7c75382 in main_signal_handler_C (xsp=0x407da3bc "R\232\303\367\v") at /home/derek/dr/git/src/core/unix/signal.c:5986
#2  0xf7c39ac1 in main_signal_handler () at /home/derek/dr/git/src/core/arch/x86/x86.asm:1460
(gdb) x/3i 0xf724fbed 
   0xf724fbed:	mov    %gs:0x4fe,%al
   0xf724fbf3:	movzbl %al,%eax
   0xf724fbf6:	movb   $0x1,%gs:0x4fe
(gdb) p shared_data
$1 = (thread_data_t *) 0x0

Hmm under gdb we don't get past this to hit the synch.c assert; from log
file w/o debugger the assert is a little later, maybe while still trying to
handle the 2nd SIGSEGV.

Fixing the check_in_last_thread_vm_area() by checking for
shared_data==NULL, and wrapping privload_call_lib_func()'s call in
TRY_EXCEPT: this test now doesn't die, but it fails and has a nice message:

240: Test command: /home/derek/dr/git/build_x86_dbg_tests/bin32/drrun "-s" "90" "-quiet" "-debug" "-killpg" "-stderr_mask" "0xC" "-dumpcore_mask" "0" "-code_api" "-c" "/home/derek/dr/git/build_x86_dbg_tests/suite/tests/bin/libclient.destructor.dll.so" "--" "/home/derek/dr/git/build_x86_dbg_tests/suite/tests/bin/client.destructor"
240: Test timeout computed to be: 1500
240: <Private library libclient.destructor.dll.so init/fini func 0xf7f44228 crashed>
240: all done
1/1 Test #240: code_api|client.destructor .......***Failed  Required regular expression not found. Regex=[^hasdtr::hasdtr
all done
hasdtr::~hasdtr
$
]  0.20 sec

This is yet more issues with private loading on recent glibc: xref #5437.

derekbruening added a commit that referenced this issue Jan 5, 2024
Wraps private library init/fini calls in a try/except on Linux (as is
already done on Windows) and reports a crash as a SYSLOG_ERROR
pointing at the library's name.  This is much better than a weird
assert or mysterious secondary crash later.

Adds a check for shared_data==NULL in check_thread_in_last_vmwarea()
to avoid a crash seen there.

Issue: #6541
derekbruening added a commit that referenced this issue Jan 5, 2024
Wraps private library init/fini calls in a try/except on Linux (as is
already done on Windows) and reports a crash as a SYSLOG_ERROR pointing
at the library's name. This is much better than a weird assert or
mysterious secondary crash later.

Adds a check for shared_data==NULL in check_thread_in_last_vmwarea() to
avoid a crash seen there.

Issue: #6541
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant