Open Bug 1265575 Opened 4 years ago Updated 3 years ago

running web-platform-tests with --debugger gdb doesn't work on Linux


(Testing :: web-platform-tests, defect)

Not set


(firefox48 affected)

Tracking Status
firefox48 --- affected


(Reporter: dbaron, Unassigned)


(Blocks 1 open bug)


Running the command:
  ./mach web-platform-tests --test-types reftest --debugger gdb
decides to suspend the running of the tests every time it hits a breakpoint / signal instead of actually dropping into gdb like it's supposed to.
Can you give a more specific example of a set of steps that don't work so that I can try to reproduce?
It was three months ago, so... not really?

Maybe try the above, if you get a "(gdb)" prompt then type "b NS_DebugBreak" and then "c" and see what happens when you hit a breakpoint?
I see it break at various times.

The first is before tests start running:

Thread 1 "firefox" received signal SIG38, Real-time event 38.
0x00007fffe8e99596 in mozilla::storage::Service::getSingleton() () from /home/jgraham/develop/gecko/obj-x86_64-pc-linux-gnu/dist/bin/

After pressing "c" running the tests start as expected. Then there is a break after running some tests at:

Thread 1 "firefox" received signal SIG38, Real-time event 38.
0x00007ffff6c3ee8d in poll () at ../sysdeps/unix/syscall-template.S:84
84	../sysdeps/unix/syscall-template.S: No such file or directory.

Again pressing c resumes the tests.

As best as I can tell this is working as expected?
"handle SIG38 nostop" would avoid those stops. You can pass that to gdb via a command-line parameter or a .gdbinit.
OK, I can do that if it's the right thing to do, but you might have to educate me. What is SIG38, or rather, why is is being signalled here? And why isn't this a problem in other harnesses? AFAIK the code for creating the gdb command line is shared (it's from mozdebug).
You need to log in before you can comment on or make changes to this bug.