go: runtime: "unexpected result from waitpid" in TestGdbPython

2020-05-12T15:01:56-a0698a6/linux-amd64-longtest

--- FAIL: TestGdbPanic (0.85s)
    runtime-gdb_test.go:71: gdb version 7.12
    runtime-gdb_test.go:616: could not find '(#.* .* in )?main\.crash' in backtrace
    runtime-gdb_test.go:617: gdb output:
        Loading Go Runtime support.
--- FAIL: TestGdbPython (0.98s)
    runtime-gdb_test.go:71: gdb version 7.12
    runtime-gdb_test.go:249: gdb output: Loading Go Runtime support.
        Loaded  Script                                                                 
        Yes     /workdir/go/src/runtime/runtime-gdb.py                                 
        Breakpoint 1 at 0x498865: file /workdir/tmp/go-build240230015/main.go, line 16.
        warning: linux_test_for_tracefork: unexpected result from waitpid (52539, status 0x1c7f)
        hi
        
    runtime-gdb_test.go:278: info goroutines failed: 
FAIL
FAIL	runtime	157.848s

This is the only occurrence I’ve seen so far. CC @ianlancetaylor in case it’s somehow related to CL 232862, which went in one CL before this failure.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 28 (26 by maintainers)

Commits related to this issue

runtime: check gdb exit status and log output All GDB tests currently ignore non-zero exit statuses. When tests flakes, we don't even know if GDB exited successfully or not. Add checks for non-zero ... — committed to golang/go by prattmic 4 years ago

Most upvoted comments

Aha! I should read kill(2) more closely: “If pid equals 0, then sig is sent to every process in the process group of the calling process.”

The original blamed http://golang.org/cl/232862 has a new test with:

	// Send ourselves SIGWINCH regularly.
	go func() {
		for range time.Tick(100 * time.Microsecond) {
			syscall.Kill(0, syscall.SIGWINCH)
		}
	}()

So that is presumably the source of the signals. I’ll send a workaround.

prattmic on May 27, 2020

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000003ffb9c009f8 in fileno_unlocked () from /lib64/libc.so.6

Thread 1 (Thread 0x3ffbade6bb0 (LWP 1048)):
#0  0x000003ffb9c009f8 in fileno_unlocked () from /lib64/libc.so.6
#1  0x000003ffbacb71be in rl_resize_terminal () from /lib64/libreadline.so.7
#2  0x000002aa08763246 in tui_async_resize_screen(void*) ()
#3  0x000002aa088dca18 in invoke_async_signal_handlers() ()
#4  0x000002aa088dd57a in gdb_do_one_event() ()
#5  0x000002aa08a23e04 in wait_sync_command_done() ()
#6  0x000002aa08a23ffc in execute_command(char const*, int) ()
#7  0x000002aa08947f26 in catch_command_errors(void (*)(char const*, int), char const*, int) ()
#8  0x000002aa0894935e in gdb_main(captured_main_args*) ()
#9  0x000002aa08686f06 in main ()

It seems like this must be some kind of GDB bug, though perhaps one we a tickling somehow.

prattmic on May 26, 2020

Could we run tests that sending signals to the process group not in parallel with other tests?

cherrymui on May 29, 2020