Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: TestSegv/Segv failure with 'unknown pc' on linux/ppc64le #52963

Closed
bcmills opened this issue May 18, 2022 · 28 comments
Closed

runtime: TestSegv/Segv failure with 'unknown pc' on linux/ppc64le #52963

bcmills opened this issue May 18, 2022 · 28 comments
Labels
arch-ppc64x compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented May 18, 2022

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        testenv.go:460: [/tmp/workdir-host-linux-riscv64-unmatched/tmp/go-build3484739273/testprogcgo.exe Segv] exit status: exit status 2
        crash_cgo_test.go:611: SIGSEGV: segmentation violation
            PC=0x3fe45b3c1a m=3 sigcode=0
            
            goroutine 0 [idle]:
            runtime: g 0: unknown pc 0x3fe45b3c1a
            stack: frame={sp:0x3fb7ffe3e0, fp:0x0} stack=[0x3fb77feb60,0x3fb7ffe760)

greplogs -l -e 'FAIL: TestSegv/Segv .*(?:\n[ ]{8}.*)*unknown pc' --since=2022-01-01
2022-05-16T19:48:35-99d6300/linux-riscv64-unmatched

Compare #50979, #47537.

(attn @golang/riscv64; CC @golang/runtime)

@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-riscv Issues solely affecting the riscv64 architecture. labels May 18, 2022
@bcmills bcmills added this to the Backlog milestone May 18, 2022
@mengzhuo
Copy link
Contributor

mengzhuo commented May 20, 2022

coredump shows the command that failed is testprogcgo CgoExternalThreadSignal crash

I'm confused by the stack shows "net.(*file).getLineFromData+0x58", which is an offset to net.data.cap inside the function.

@mengzhuo
Copy link
Contributor

@prattmic @cherrymui any advise?

@cherrymui
Copy link
Member

The signal PC 0x3fe45b3c1a is weird. It doesn't look like a Go PC. If you have a core dump, can you check what that address is? Does it belong to (say) a memory mapping of a C shared library?

@mengzhuo
Copy link
Contributor

No mapping around 0x3fe45b3c1a.

Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
             0x10000           0x22c000   0x21c000        0x0 /tmp/workdir-host-linux-riscv64-unmatched/tmp/go-build3484739273/testprogcgo.exe
            0x22c000           0x22d000     0x1000   0x21b000 /tmp/workdir-host-linux-riscv64-unmatched/tmp/go-build3484739273/testprogcgo.exe
            0x22d000           0x249000    0x1c000   0x21c000 /tmp/workdir-host-linux-riscv64-unmatched/tmp/go-build3484739273/testprogcgo.exe
        0x3fc176b000       0x3fc186e000   0x103000        0x0 /usr/lib/riscv64-linux-gnu/libc-2.33.so
        0x3fc186e000       0x3fc1871000     0x3000   0x102000 /usr/lib/riscv64-linux-gnu/libc-2.33.so
        0x3fc1871000       0x3fc1874000     0x3000   0x105000 /usr/lib/riscv64-linux-gnu/libc-2.33.so
        0x3fc187c000       0x3fc1890000    0x14000        0x0 /usr/lib/riscv64-linux-gnu/libpthread-2.33.so
        0x3fc1890000       0x3fc1891000     0x1000    0x13000 /usr/lib/riscv64-linux-gnu/libpthread-2.33.so
        0x3fc1891000       0x3fc1892000     0x1000    0x14000 /usr/lib/riscv64-linux-gnu/libpthread-2.33.so
        0x3fc18a2000       0x3fc18bd000    0x1b000        0x0 /usr/lib/riscv64-linux-gnu/ld-2.33.so
        0x3fc18be000       0x3fc18bf000     0x1000    0x1b000 /usr/lib/riscv64-linux-gnu/ld-2.33.so
        0x3fc18bf000       0x3fc18c1000     0x2000    0x1c000 /usr/lib/riscv64-linux-gnu/ld-2.33.so

maintenance info sections:
...
[71]     0x3fc18a2000->0x3fc18a3000 at 0x05a8c000: load47a ALLOC LOAD READONLY CODE HAS_CONTENTS
[72]     0x3fc18a3000->0x3fc18bd000 at 0x05a8d000: load47b ALLOC READONLY CODE
[73]     0x3fc18be000->0x3fc18bf000 at 0x05a8d000: load48 ALLOC LOAD READONLY HAS_CONTENTS
[74]     0x3fc18bf000->0x3fc18c1000 at 0x05a8e000: load49 ALLOC LOAD HAS_CONTENTS
[75]     0x3fffea7000->0x3fffec8000 at 0x05a90000: load50 ALLOC LOAD HAS_CONTENTS

@prattmic
Copy link
Member

prattmic commented May 24, 2022

Just to double check, that is from the core dump of the exact crash shown above, not a different run, correct? Because those mappings seem similar enough for 0x3fe45b3c1a to be the randomized load address in a different run.

@mengzhuo
Copy link
Contributor

Yes, It's from coredumpctl and here is the file
core_issue_52963.gz

I've tried to run the test 100 times and no luck.

@cherrymui
Copy link
Member

Thanks. Then the address is not a PC at all. It's unclear to me how we get there, or how it gets into the signal context.

@mengzhuo
Copy link
Contributor

Debug logs, Something is weird.
Failed log shows frame.pc should be 3fb7ffe548, but findfunc got a 3fe45b3c1a.

            0x0000003fb7ffe3e0: <0x0000003fb7ffe480  0x00000000000f4240 <net.(*file).getLineFromData+0x0000000000000058> 
            0x0000003fb7ffe3f0:  0x0000003fb7ffe548  0x000000000010efb6 
            0x0000003fb7ffe400:  0x00000000000f4240 <net.(*file).getLineFromData+0x0000000000000058>  0x0000003fb7ffe560 

This frame.lr != 0 so it should be two defer of frame.sp 0x3fb7ffe560 but unfortunately corefile didn't dump those memory.

IMHO three possible explanations:

  1. compiler error that miscompiled two defers(will look into)
  2. frame stack had changed before frame.pc defers (highly likely)
  3. regabi misuse register (accident clobber? I double it)

@cherrymui
Copy link
Member

frame.pc should be 3fb7ffe548

Where did you see that? I didn't see it.

PC=0x3fe45b3c1a m=3 sigcode=0

This line is printed from the signal handler, which indicates the signal context's PC is 0x3fe45b3c1a. For such a bad PC I don't think the traceback code can do anything useful. The question is why we get such a PC in the signal context.

@mengzhuo
Copy link
Contributor

mengzhuo commented May 26, 2022

frame.pc should be 3fb7ffe548

Where did you see that? I didn't see it.

Just my understand on frame stack:

            0x0000003fb7ffe3e0: <0x0000003fb7ffe480  0x00000000000f4240 <net.(*file).getLineFromData+0x0000000000000058> 
            0x0000003fb7ffe3f0:  0x0000003fb7ffe548  0x000000000010efb6 
            0x0000003fb7ffe400:  0x00000000000f4240 <net.(*file).getLineFromData+0x0000000000000058>  0x0000003fb7ffe560 
            0x0000003fb7ffe410:  0x000000000010efb6  0x8458d8a6295c2900 

which aligned with frame struct

// stack traces
type stkframe struct {
	fn       funcInfo   // 0x0000003fb7ffe480  0x00000000000f4240
	pc       uintptr    // 0x0000003fb7ffe548
	continpc uintptr    // 0x000000000010efb6
	lr       uintptr    // 0x00000000000f4240 
	sp       uintptr    // 0x0000003fb7ffe560 
	fp       uintptr    // 0x000000000010efb6  
	varp     uintptr    // 0x8458d8a6295c2900 
        .....
}

The question is why we get such a PC in the signal context.

The code seems fine (why sigcode=0?)
The ucontext with cgo padding didn't generated by cgo, misaligned?

runtime/defs_linux_riscv64.go

type ucontext struct {
	uc_flags     uint64
	uc_link      *ucontext
	uc_stack     stackt
	uc_sigmask   usigset
	uc_x__unused [0]uint8 // according to signal.h it's 0
	uc_pad_cgo_0 [8]byte
	uc_mcontext  sigcontext
}

@cherrymui
Copy link
Member

No. That hex dump is not the stkframe structure. They are unrelated. Also, traceback probably doesn't matter here. We start with a bad signal PC in the first place.

why sigcode=0?

sigcode=0 (i.e. _SI_USER) is expected. The test is testing a user-sent SIGSEGV.

Hmmm, if the ucontext fields are wrong, I'd think many things would go wrong, not just this failure.

@mengzhuo
Copy link
Contributor

You're right about ucontext fields.
I tried setting this padding to 0 and can't even build it.

@cherrymui
Copy link
Member

The LR is 0x10f0f2. Could you look at the core and see what that address is? It is not a Go PC either. But it belongs to the program's mapping. PLT stub?

@mengzhuo
Copy link
Contributor

The original binary had been deleted so I rebuild with the commit 99d6300
0x10f0f2 -> gcc_linux_riscv64.c:36

err = _cgo_try_pthread_create(&p, &attr, threadentry, ts);
pthread_sigmask(SIG_SETMASK, &oset, nil);
if (err != 0) {
fatalf("pthread_create failed: %s", strerror(err));
}

@cherrymui
Copy link
Member

Thanks. Could you disassemble to function and see if it is a PC immediately after a call instruction? It looks like it is. It is calling into libc (or libpthread). Maybe the C library is doing something weird (especially when it is manipulating the signal mask)?

@mengzhuo
Copy link
Contributor

mengzhuo commented May 27, 2022

Here is the binary testprogcgo.zip

0000000000013940 <pthread_sigmask@plt>:                                                      
   13940:       00232e17                auipc   t3,0x232                                     
   13944:       340e3e03                ld      t3,832(t3) # 245c80 <pthread_sigmask@GLIBC_2.
32>                                                                                          
   13948:       000e0367                jalr    t1,t3                                        
   0x3ff7f0cbec <__GI___pthread_sigmask>           auipc   a6,0xa5                                            
   0x3ff7f0cbf0 <__GI___pthread_sigmask+4>         ld      a6,1948(a6)                                        
   0x3ff7f0cbf4 <__GI___pthread_sigmask+8>         ld      a4,0(a6)                                           
   0x3ff7f0cbf8 <__GI___pthread_sigmask+12>        addi    sp,sp,-160                                         
   0x3ff7f0cbfa <__GI___pthread_sigmask+14>        mv      a5,a1                                              
   0x3ff7f0cbfc <__GI___pthread_sigmask+16>        sd      ra,152(sp)                                         
   0x3ff7f0cbfe <__GI___pthread_sigmask+18>        sd      a4,136(sp)                                         
   0x3ff7f0cc00 <__GI___pthread_sigmask+20>        li      a1,0                                               
   0x3ff7f0cc02 <__GI___pthread_sigmask+22>        beqz    a5,0x3ff7f0cc10 <__GI___pthread_sigmask+36>        
   0x3ff7f0cc04 <__GI___pthread_sigmask+24>        ld      a3,0(a5)                                           
   0x3ff7f0cc06 <__GI___pthread_sigmask+26>        li      a4,3                                               
   0x3ff7f0cc08 <__GI___pthread_sigmask+28>        slli    a4,a4,0x1f                                         
   0x3ff7f0cc0a <__GI___pthread_sigmask+30>        and     a4,a4,a3                                           
   0x3ff7f0cc0c <__GI___pthread_sigmask+32>        bnez    a4,0x3ff7f0cc3c <__GI___pthread_sigmask+80>        
   0x3ff7f0cc0e <__GI___pthread_sigmask+34>        mv      a1,a5                                              
   0x3ff7f0cc10 <__GI___pthread_sigmask+36>        li      a7,135                                             
   0x3ff7f0cc14 <__GI___pthread_sigmask+40>        li      a3,8                                               
   0x3ff7f0cc16 <__GI___pthread_sigmask+42>        ecall                                                      
   0x3ff7f0cc1a <__GI___pthread_sigmask+46>        lui     a4,0xfffff                                         
   0x3ff7f0cc1c <__GI___pthread_sigmask+48>        sext.w  a3,a0                                              
   0x3ff7f0cc20 <__GI___pthread_sigmask+52>        mv      a5,a0                                              
   0x3ff7f0cc22 <__GI___pthread_sigmask+54>        li      a0,0                                               
   0x3ff7f0cc24 <__GI___pthread_sigmask+56>        bgeu    a4,a3,0x3ff7f0cc2c <__GI___pthread_sigmask+64>     
   0x3ff7f0cc28 <__GI___pthread_sigmask+60>        negw    a0,a5                                              
   0x3ff7f0cc2c <__GI___pthread_sigmask+64>        ld      a4,136(sp)                                         
   0x3ff7f0cc2e <__GI___pthread_sigmask+66>        ld      a5,0(a6)                                           
   0x3ff7f0cc32 <__GI___pthread_sigmask+70>        bne     a4,a5,0x3ff7f0cc7c <__GI___pthread_sigmask+144>  
   0x3ff7f0cc36 <__GI___pthread_sigmask+74>        ld      ra,152(sp)                                      
   0x3ff7f0cc38 <__GI___pthread_sigmask+76>        addi    sp,sp,160                                       
   0x3ff7f0cc3a <__GI___pthread_sigmask+78>        ret                                                     
   0x3ff7f0cc3c <__GI___pthread_sigmask+80>        addi    a1,sp,8                                         
   0x3ff7f0cc3e <__GI___pthread_sigmask+82>        mv      a4,a1                                           
   0x3ff7f0cc40 <__GI___pthread_sigmask+84>        addi    t5,a5,128                                       
   0x3ff7f0cc44 <__GI___pthread_sigmask+88>        ld      t4,0(a5)                                        
   0x3ff7f0cc48 <__GI___pthread_sigmask+92>        ld      t3,8(a5)                                        
   0x3ff7f0cc4c <__GI___pthread_sigmask+96>        ld      t1,16(a5)                                       
   0x3ff7f0cc50 <__GI___pthread_sigmask+100>       ld      a7,24(a5)                                       
   0x3ff7f0cc54 <__GI___pthread_sigmask+104>       sd      t4,0(a4)                                        
   0x3ff7f0cc58 <__GI___pthread_sigmask+108>       sd      t3,8(a4)                                        
   0x3ff7f0cc5c <__GI___pthread_sigmask+112>       sd      t1,16(a4)                                       
   0x3ff7f0cc60 <__GI___pthread_sigmask+116>       sd      a7,24(a4)                                       
   0x3ff7f0cc64 <__GI___pthread_sigmask+120>       addi    a5,a5,32                                        
   0x3ff7f0cc68 <__GI___pthread_sigmask+124>       addi    a4,a4,32                                        
   0x3ff7f0cc6c <__GI___pthread_sigmask+128>       bne     a5,t5,0x3ff7f0cc44 <__GI___pthread_sigmask+88>  
   0x3ff7f0cc70 <__GI___pthread_sigmask+132>       li      a5,-3                                           
   0x3ff7f0cc72 <__GI___pthread_sigmask+134>       slli    a5,a5,0x1f                                      
   0x3ff7f0cc74 <__GI___pthread_sigmask+136>       addi    a5,a5,-1                                        
   0x3ff7f0cc76 <__GI___pthread_sigmask+138>       and     a3,a3,a5                                        
   0x3ff7f0cc78 <__GI___pthread_sigmask+140>       sd      a3,8(sp)                                        
   0x3ff7f0cc7a <__GI___pthread_sigmask+142>       j       0x3ff7f0cc10 <__GI___pthread_sigmask+36>        
   0x3ff7f0cc7c <__GI___pthread_sigmask+144>       jal     ra,0x3ff7f5bf40 <__stack_chk_fail>              

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
@pmur
Copy link
Contributor

pmur commented Sep 9, 2022

I think a couple recent failures on the ppc64le builder are related. I turned off ASLR on the ppc64le builder and eventually reproduced a similar failure trying to reproduce on the ppc64le VM.

2022-09-08T21:16:39-a9a3982/linux-ppc64le-buildlet
2022-08-10T17:59:59-9f8685f/linux-ppc64le-power9osu

The PC is within libc's pthread_sigmask, called from _cgo_sys_thread_start.

@gopherbot
Copy link

Change https://go.dev/cl/430375 mentions this issue: runtime: ignore "unknown pc" error in TestSegv/Segv

@bcmills bcmills changed the title runtime: TestSegv/Segv failure with 'unknown pc' on linux-riscv64-unmatched runtime: TestSegv/Segv failure with 'unknown pc' on linux/riscv64 and linux/ppc64le Sep 14, 2022
@bcmills
Copy link
Contributor Author

bcmills commented Sep 14, 2022

Indeed, the failure mode at least matches the same pattern. It's not clear to me whether the underlying cause is the same.

greplogs -l -e 'FAIL: TestSegv/Segv .*(?:\n[ ]{8}.*)*unknown pc' --since=2022-05-18
2022-09-08T21:16:39-a9a3982/linux-ppc64le-buildlet
2022-08-10T17:59:59-9f8685f/linux-ppc64le-power9osu

CC @golang/ppc64

@laboger
Copy link
Contributor

laboger commented Oct 4, 2022

Indeed, the failure mode at least matches the same pattern. It's not clear to me whether the underlying cause is the same.

These look very similar. In the above debugging and in Paul's debugging, it ended up in the pthread_sigmask code. Also, in all the logs where it fails, the stack trace shows that the goroutine for Segv.func1 is calling preemption code. If I run the test manually and it passes, I don't see preempt code in the stack trace.

I don't know all the details of what happens during preemption. Perhaps another goroutine or thread starts running so the test ends up sending the SEGV signal to the wrong one which happens to be C code. Then the Go backtrace doesn't always work since slot 0 in the stack frame is the backchain for the stack and not a PC like it is in Go code, and that commonly results in that unknown PC error.

@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2022-08-10 17:59 linux-ppc64le-power9osu go@9f8685f4 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        testenv.go:473: [/workdir/tmp/go-build528637846/testprogcgo.exe Segv] exit status: exit status 2
        crash_cgo_test.go:611: SIGSEGV: segmentation violation
            PC=0x7c9399b43a14 m=3 sigcode=0

            r0   0xae	r1   0x7c9369abe0d0
            r2   0x7c9399b77f00	r3   0x0
            r4   0x7c9369abe200	r5   0x0
            r6   0x8	r7   0x0
            r8   0x7c937126f588	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x7c9369ac68d0
            r14  0x0	r15  0x7c9371270b30
            r16  0x1a0	r17  0xc0000821a0
            r18  0x178	r19  0x1fffff
            r20  0x0	r21  0xc000080000
            r22  0x7c93692bed88	r23  0x3000
            r24  0x38	r25  0xffffffff80000000
            r26  0x0	r27  0x0
            r28  0x1006b6ec	r29  0x2
            r30  0x0	r31  0x0
            pc   0x7c9399b43a14	ctr  0x0
            link 0x101148b8	xer  0x0
            ccr  0x44424482	trap 0xc00

        crash_cgo_test.go:638: unexpectedly saw "runtime: " in output
2022-09-08 21:16 linux-ppc64le-buildlet go@a9a39822 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.03s)
        testenv.go:468: [/workdir/tmp/go-build2014546259/testprogcgo.exe Segv] exit status: exit status 2
        crash_cgo_test.go:611: SIGSEGV: segmentation violation
            PC=0x750cd6973a14 m=6 sigcode=0

            r0   0xae	r1   0x750cad17e0c0
            r2   0x750cd69a7f00	r3   0x0
            r4   0x750cad17e1f0	r5   0x0
            r6   0x8	r7   0x0
            r8   0x750c97fff588	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x750cad1868d0
            r14  0x0	r15  0x750cad182d30
            r16  0x1a0	r17  0xc0001021a0
            r18  0x0	r19  0xc000102000
            r20  0x1	r21  0xc000100000
            r22  0x750cac97ed88	r23  0x750cad17e248
            r24  0x0	r25  0x1
            r26  0x0	r27  0x40
            r28  0xffffffffffffffff	r29  0x2
            r30  0x0	r31  0x0
            pc   0x750cd6973a14	ctr  0x0
            link 0x101164f8	xer  0x0
            ccr  0x24424482	trap 0xc00

        crash_cgo_test.go:638: unexpectedly saw "runtime: " in output
2022-09-21 15:30 linux-ppc64le-power9osu go@e246cf62 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        testenv.go:468: [/workdir/tmp/go-build673890005/testprogcgo.exe Segv] exit status: exit status 2
        crash_cgo_test.go:617: SIGSEGV: segmentation violation
            PC=0x76f6671d3a14 m=4 sigcode=0

            r0   0xae	r1   0x76f63ea3e090
            r2   0x76f667207f00	r3   0x0
            r4   0x76f63ea3e1c0	r5   0x0
            r6   0x8	r7   0x0
            r8   0x76f63d18f588	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x76f63ea468d0
            r14  0x0	r15  0x76f63d9e2d30
            r16  0x1a0	r17  0xc0001021a0
            r18  0x0	r19  0xc000102000
            r20  0x1	r21  0xc000100000
            r22  0x76f63e23ed88	r23  0x76f63ea3e218
            r24  0x0	r25  0x1
            r26  0x0	r27  0x38
            r28  0xffffffffffffffff	r29  0x2
            r30  0x0	r31  0x0
            pc   0x76f6671d3a14	ctr  0x0
            link 0x10116e78	xer  0x0
            ccr  0x24424482	trap 0xc00

        crash_cgo_test.go:648: unexpectedly saw "runtime: " in output

watchflakes

@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2023-01-17 19:54 linux-ppc64le-power10osu go@b003ee49 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        crash_test.go:58: /workdir/tmp/go-build1118117851/testprogcgo.exe Segv: exit status 2
        crash_cgo_test.go:620: SIGSEGV: segmentation violation
            PC=0x7deeb7a35394 m=4 sigcode=0

            r0   0xae	r1   0x7dee8f3de0b0
            r2   0x7deeb7a67f00	r3   0x0
            r4   0x7dee8f3de1e0	r5   0x0
            r6   0x8	r7   0x0
            r8   0x7dee8db2f598	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x7dee8f3e68e0
            r14  0x0	r15  0x0
            r16  0x0	r17  0x2
            r18  0x2	r19  0x0
            r20  0x7deeb7640000	r21  0xc000100000
            r22  0x7dee8ebdeda8	r23  0x7dee8f3de238
            r24  0x0	r25  0x7dee8f3df8e0
            r26  0x7dee8f3dea70	r27  0x7fffe99c86e0
            r28  0x7fffe99c842f	r29  0x7dee8f3df170
            r30  0x2	r31  0x0
            pc   0x7deeb7a35394	ctr  0x0
            link 0x101262fc	xer  0x0
            ccr  0x24424488	trap 0xc00

        crash_cgo_test.go:651: unexpectedly saw "runtime: " in output

watchflakes

@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2023-01-31 17:44 linux-ppc64le-power10osu go@7d7fd6d3 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        crash_test.go:58: /workdir/tmp/go-build1815239492/testprogcgo.exe Segv: exit status 2
        crash_cgo_test.go:620: SIGSEGV: segmentation violation
            PC=0x71559f025394 m=4 sigcode=0

            r0   0xae	r1   0x7155769ce0d0
            r2   0x71559f057f00	r3   0x0
            r4   0x7155769ce2d8	r5   0x0
            r6   0x8	r7   0x0
            r8   0x71557511f598	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x7155769d68e0
            r14  0x0	r15  0x0
            r16  0x66	r17  0xffffffffffffffff
            r18  0x1	r19  0x1
            r20  0x0	r21  0xc00003b000
            r22  0x7155761cedb0	r23  0x7155769ce268
            r24  0x2	r25  0x7155769cf8e0
            r26  0x7155769cea70	r27  0x7ffff5686ae0
            r28  0x7ffff56868ff	r29  0x7155769ce220
            r30  0x2	r31  0x0
            pc   0x71559f025394	ctr  0x0
            link 0x1012acf8	xer  0x0
            ccr  0x24424480	trap 0xc00

        crash_cgo_test.go:651: unexpectedly saw "runtime: " in output

watchflakes

@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2023-02-27 19:11 linux-ppc64le-power9osu go@132fae93 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        crash_cgo_test.go:619: /workdir/tmp/go-build1507686471/testprogcgo.exe Segv: exit status 2
        crash_cgo_test.go:620: SIGSEGV: segmentation violation
            PC=0x724c52235394 m=4 sigcode=0

            r0   0xae	r1   0x724c29bde0b0
            r2   0x724c52267f00	r3   0x0
            r4   0x724c29bde1e0	r5   0x0
            r6   0x8	r7   0x0
            r8   0x724c13fff598	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x724c29be68e0
            r14  0x0	r15  0x0
            r16  0x1	r17  0x10000000000
            r18  0x724c2ad24088	r19  0x0
            r20  0x31	r21  0x188
            r22  0x724c293dedb0	r23  0x724c29bde238
            r24  0x1	r25  0x724c29bdf8e0
            r26  0x724c29bdea70	r27  0x7fffda4b39d0
            r28  0x7fffda4b371f	r29  0x724c29bdf170
            r30  0x2	r31  0x0
            pc   0x724c52235394	ctr  0x0
            link 0x10129b5c	xer  0x0
            ccr  0x24424488	trap 0xc00

        crash_cgo_test.go:651: unexpectedly saw "runtime: " in output

watchflakes

@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2023-03-22 11:02 linux-ppc64le-buildlet go@9b6231a1 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        crash_cgo_test.go:622: /workdir/tmp/go-build3572851245/testprogcgo.exe Segv: exit status 2
        crash_cgo_test.go:623: SIGSEGV: segmentation violation
            PC=0x7d4cbcef5394 m=4 sigcode=0

            r0   0xae	r1   0x7d4c9489e0b0
            r2   0x7d4cbcf27f00	r3   0x0
            r4   0x7d4c9489e1e0	r5   0x0
            r6   0x8	r7   0x0
            r8   0x7d4c8efdf598	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x7d4c948a68e0
            r14  0x0	r15  0x0
            r16  0x1	r17  0x10000000000
            r18  0x7d4c959e4088	r19  0x0
            r20  0x31	r21  0x188
            r22  0x7d4c9409edb0	r23  0x7d4c9489e238
            r24  0x1	r25  0x7d4c9489f8e0
            r26  0x7d4c9489ea70	r27  0x7fffd6575c90
            r28  0x7fffd65759df	r29  0x7d4c9489f170
            r30  0x2	r31  0x0
            pc   0x7d4cbcef5394	ctr  0x0
            link 0x1012a8fc	xer  0x0
            ccr  0x24424488	trap 0xc00

        crash_cgo_test.go:654: unexpectedly saw "runtime: " in output

watchflakes

@bcmills bcmills changed the title runtime: TestSegv/Segv failure with 'unknown pc' on linux/riscv64 and linux/ppc64le runtime: TestSegv/Segv failure with 'unknown pc' on linux/ppc64le Apr 11, 2023
@bcmills bcmills removed the arch-riscv Issues solely affecting the riscv64 architecture. label Apr 11, 2023
@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2023-05-02 15:36 linux-ppc64le-buildlet go@2d83b646 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.03s)
        crash_cgo_test.go:641: /workdir/tmp/go-build2920624392/testprogcgo.exe Segv: exit status 2
        crash_cgo_test.go:642: SIGSEGV: segmentation violation
            PC=0x7b713e305394 m=3 sigcode=0

            r0   0xae	r1   0x7b70eecbe0e0
            r2   0x7b713e337f00	r3   0x0
            r4   0x7b70eecbe210	r5   0x0
            r6   0x8	r7   0x0
            r8   0x7b70f5c1f598	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x7b70eecc68e0
            r14  0x0	r15  0x0
            r16  0x1	r17  0x10000000000
            r18  0x7b70f75f2088	r19  0x0
            r20  0x31	r21  0x188
            r22  0x7b70ee4bedb0	r23  0x7b70eecbe268
            r24  0x0	r25  0x7b70eecbf8e0
            r26  0x7b70eecbea70	r27  0x7fffe299f100
            r28  0x7fffe299ee4f	r29  0x7b70eecbf170
            r30  0x2	r31  0x0
            pc   0x7b713e305394	ctr  0x0
            link 0x1012e77c	xer  0x0
            ccr  0x24424488	trap 0xc00

        crash_cgo_test.go:673: unexpectedly saw "runtime: " in output

watchflakes

@gopherbot
Copy link

Found new dashboard test flakes for:

#!watchflakes
post <- goarch == "ppc64le" && pkg == "runtime" && test == "TestSegv" && `unknown pc`
2023-05-12 12:35 linux-ppc64le-power10osu go@b26c3927 runtime.TestSegv (log)
--- FAIL: TestSegv (0.00s)
    --- FAIL: TestSegv/Segv (0.02s)
        crash_cgo_test.go:648: /workdir/tmp/go-build2331561012/testprogcgo.exe Segv: exit status 2
        crash_cgo_test.go:649: SIGSEGV: segmentation violation
            PC=0x741ef34f0ee8 m=4 sigcode=0

            r0   0xae	r1   0x741eab86de20
            r2   0x741ef36b6e00	r3   0x0
            r4   0x741eab86df50	r5   0x0
            r6   0x8	r7   0x0
            r8   0x0	r9   0x0
            r10  0x0	r11  0x0
            r12  0x0	r13  0x741eab8768e0
            r14  0x0	r15  0x0
            r16  0x1	r17  0x10000000000
            r18  0x741eac9b4088	r19  0x0
            r20  0x31	r21  0x188
            r22  0x741eab06eb38	r23  0x741eab86dfa8
            r24  0x14860540	r25  0x10132330
            r26  0x7fffc170caf0	r27  0x0
            r28  0x741eab86dfd0	r29  0x14860540
            r30  0x2	r31  0x0
            pc   0x741ef34f0ee8	ctr  0x0
            link 0x0	xer  0x0
            ccr  0x44424488	trap 0x3000

        crash_cgo_test.go:680: unexpectedly saw "runtime: " in output

watchflakes

@gopherbot
Copy link

Change https://go.dev/cl/500535 mentions this issue: runtime: move Segv and TgkillSegv to testprog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-ppc64x compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: Done
Development

No branches or pull requests

7 participants