Open tysmith opened 5 months ago
I can reproduce this fairly consistently with a Firefox debug build loading http://saleepoch.com
. --chaos
might be required. It only seems to happen after a browser crash/assertion is triggered.
Sorry for the delay Tyson... can you still reproduce this? Can you pass -F to rr record, forcing it to stop, and get an rr stack trace?
Hey no problem :)
I am seeing this consistently when using our tools but when I try to reproduce it using just rr and Firefox I cannot. I've tried to isolate specific environment tweaks that trigger the issue but I've been unsuccessful.
I've logged #3748 to propose a way to help collect debugging issue in a manner more compatible with automation/non-interactive mode.
I have reduced the STR further. I think the issue might be related to the code writing minidumps.
MOZ_CRASHREPORTER=1 MOZ_CRASHREPORTER_NO_DELETE_DUMP=1 MOZ_CRASHREPORTER_NO_REPORT=1 MOZ_CRASHREPORTER_SHUTDOWN=1 MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_DISABLE_GMP_SANDBOX=1 MOZ_DISABLE_GPU_SANDBOX=1 MOZ_DISABLE_NPAPI_SANDBOX=1 MOZ_DISABLE_PDFIUM_SANDBOX=1 MOZ_DISABLE_RDD_SANDBOX=1 MOZ_DISABLE_SOCKET_PROCESS_SANDBOX=1 MOZ_DISABLE_UTILITY_SANDBOX=1 rr record ./firefox -no-remote -profile <empty-dir>
about:crashcontent
to trigger the issue.I can reproduce that, thanks.
rr stack
(gdb) bt
#0 0x000073389bf2745f in accept () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00005e0141f2c9bb in rr::GdbServerConnection::await_debugger (this=0x5e0143cd0fe0, listen_fd=...)
at /home/khuey/dev/rr/src/GdbServerConnection.cc:120
#2 0x00005e0141f2c91e in rr::GdbServerConnection::await_connection (t=0x5e0143caf720, listen_fd=...,
features=...) at /home/khuey/dev/rr/src/GdbServerConnection.cc:115
#3 0x00005e0141f9b00f in rr::emergency_debug (t=0x5e0143caf720)
at /home/khuey/dev/rr/src/launch_debugger.cc:400
#4 0x00005e0141f9eeee in rr::start_emergency_debug (t=0x5e0143caf720) at /home/khuey/dev/rr/src/log.cc:494
#5 0x00005e0141f9f1b3 in rr::EmergencyDebugOstream::~EmergencyDebugOstream (this=0x7ffef8ec60e0,
__in_chrg=<optimized out>) at /home/khuey/dev/rr/src/log.cc:516
#6 0x00005e0142154e80 in rr::Task::regs (this=0x5e0143caf720) at /home/khuey/dev/rr/src/Task.cc:1163
#7 0x00005e014205f27c in rr::prepare_ptrace_legacy<rr::X64Arch> (t=0x5e0143b29ce0, syscall_state=...)
at /home/khuey/dev/rr/src/record_syscall.cc:2599
#8 0x00005e0142054035 in rr::prepare_ptrace<rr::X64Arch> (t=0x5e0143b29ce0, syscall_state=...)
at /home/khuey/dev/rr/src/record_syscall.cc:3177
#9 0x00005e0142034cd8 in rr::rec_prepare_syscall_arch<rr::X64Arch> (t=0x5e0143b29ce0, syscall_state=...,
regs=...) at /home/khuey/dev/rr/src/record_syscall.cc:5041
#10 0x00005e0142020cba in operator() (__closure=0x7ffef8ec7090, regs=...)
at /home/khuey/dev/rr/src/record_syscall.cc:5401
#11 0x00005e014203c5f2 in rr::with_converted_registers<rr::Switchable, rr::rec_prepare_syscall_internal(rr::RecordTask*, rr::TaskSyscallState&)::<lambda(const rr::Registers&)> >(const rr::Registers &, rr::SupportedArch, struct {...}) (regs=..., arch=rr::x86_64, f=...) at /home/khuey/dev/rr/src/Registers.h:630
#12 0x00005e0142020d99 in rr::rec_prepare_syscall_internal (t=0x5e0143b29ce0, syscall_state=...)
at /home/khuey/dev/rr/src/record_syscall.cc:5399
#13 0x00005e0142020e3e in rr::rec_prepare_syscall (t=0x5e0143b29ce0)
at /home/khuey/dev/rr/src/record_syscall.cc:5411
#14 0x00005e0142000aae in rr::RecordSession::syscall_state_changed (this=0x5e0143ab1f10, t=0x5e0143b29ce0,
step_state=0x7ffef8ec755c) at /home/khuey/dev/rr/src/RecordSession.cc:1177
#15 0x00005e01420081e6 in rr::RecordSession::record_step (this=0x5e0143ab1f10)
at /home/khuey/dev/rr/src/RecordSession.cc:2678
#16 0x00005e0141ff9c87 in rr::record (args=..., flags=...) at /home/khuey/dev/rr/src/RecordCommand.cc:711
#17 0x00005e0141ffaae2 in rr::RecordCommand::run (this=0x5e01423de1a0 <rr::RecordCommand::singleton>,
args=...) at /home/khuey/dev/rr/src/RecordCommand.cc:874
#18 0x00005e0141fb2d58 in main (argc=5, argv=0x7ffef8ec79a8) at /home/khuey/dev/rr/src/main.cc:278
(gdb)
The rough sequence of events here is
I tried writing a test case for this but I actually triggered a different rr bug :/
Hey @khuey I'm getting blocked by this again. If you could please have a look when you have some free time I'd really appreciate it. I double checked the above STR still work for me using commit 77f88f4.
Found with Firefox debug build m-c
20240428-d1651fe33156
https://firefox-ci-tc.services.mozilla.com/tasks/index/gecko.v2.mozilla-central.revision.d1651fe33156a2aab5884ab1eaaaa8c5dd64631d.firefox/linux64-debug
This was triggered during recording using rr commit 2bb38b94.