David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Reporter
	Description • 8 years ago

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.

	James Graham [:jgraham]
	Comment 1 • 8 years ago

Can you give a more specific example of a set of steps that don't work so that I can try to reproduce?

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla) Reporter
	Comment 2 • 8 years ago

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?

	James Graham [:jgraham]
	Comment 3 • 8 years ago

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/libxul.so

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?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 4 • 8 years ago

"handle SIG38 nostop" would avoid those stops. You can pass that to gdb via a command-line parameter or a .gdbinit.

	James Graham [:jgraham]
	Comment 5 • 8 years ago

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).