Debugging "AddressSanitizer: nested bug in the same thread"

[Maksim Ivanov]

Hello,

I'm trying to investigate a crash in my code ported to WebAssembly, and was hoping to get additional information using Address Sanitizer. Unfortunately, ASan fails too, with the following error:

  "AddressSanitizer: nested bug in the same thread, aborting."

There's no stack trace attached to this message. I don't know if this problem is related to some Emscripten-specific ASan+threading issues (like github.com/emscripten-core/emscripten/issues/13205; however, unlike that issue, the "nested bug" is reproducible both under Node.js and Chrome).

Anyway, does anyone have a tip on how such a failure could be debugged?

Apparently, DevTools misses this failure even when "Pause on exceptions" is turned on, so that the execution continues until the point "program exited (with status: 1)" is logged - obviously, without any traceback.

Thanks,

Maksim

[Maksim Ivanov]

As a more narrow question, could anyone point me to the analog of gdb's

"catch syscall exit exit_group"

in DevTools Wasm debugging?

[Sam Clegg]

On Mon, Feb 15, 2021 at 3:40 PM 'Maksim Ivanov' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

As a more narrow question, could anyone point me to the analog of gdb's

"catch syscall exit exit_group"

Are you asking about exit in particular or syscalls in general?    devtools is not aware specifically of syscalls, but all the "syscalls" in emscripten are implemented in JS so you should be able to set breakpoints in them just fine.  Is that not working for some reason? 

 

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAH%3DwB8yinRO3XppT3Trm1o-633LR8SZuhg9beMRjp_LfrYCgrg%40mail.gmail.com.

[Maksim Ivanov]

I'm mostly interested about the exit_group syscall, since, AFAICS, that's what ASan is calling on the "nested bug" failure. (Although, I guess, a hint on how to set a breakpoint on syscall in wasm can be of general interest as well - I couldn't find it in any docs.)

I tried setting a breakpoint on the JS function that I found - ___sys_exit_group - but apparently this code is triggered asynchronously, without showing the stack trace of the actual failure that called it:

___sys_exit_group @ index.js:6207
_emscripten_receive_on_main_thread_js @ index.js:8708
_do_call @ module.wasm:0x6a08c0
emscripten_current_thread_process_queued_calls @ module.wasm:0x69ffeb
emscripten_main_thread_process_queued_calls @ module.wasm:0x6a375c
(anonymous) @ index.js:2374
worker.onmessage @ index.js:3180

So is there a way to set a breakpoint on the syscall's C/C++ implementation? So that the stack trace contains the code that actually called this syscall?

Maksim

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_zyGEG6Uhg4JguaVTAtBvk0_xzx%3DtUWqKocSA-j0pHGQ%40mail.gmail.com.