suspect sigsegv in scm_call_n

[jhelberg]

I see a crash in scm_call_n once in a while (called from scm_public_ref, which is called from Eval) and was wondering if the thread-model of guile maybe collides with the goroutines of go? I can't reproduce the crash in a test-program, but the production-program runs 12 to 14 scheme-expressions and then crashes.

Before -g compiling guile to step through the code, I was wondering whether it is actually safe to mix the two coroutines/threads without taking special precautions.

The code in scm_call_n is (amd64 code):

Dump of assembler code for function scm_call_n:
   0x00007ffff7f25100 <+0>:	endbr64 
   0x00007ffff7f25104 <+4>:	push   %r14
   0x00007ffff7f25106 <+6>:	push   %r13
   0x00007ffff7f25108 <+8>:	push   %r12
   0x00007ffff7f2510a <+10>:	mov    %rdx,%r12
   0x00007ffff7f2510d <+13>:	push   %rbp
   0x00007ffff7f2510e <+14>:	mov    %rdi,%rbp
   0x00007ffff7f25111 <+17>:	push   %rbx
   0x00007ffff7f25112 <+18>:	mov    %rsi,%rbx
   0x00007ffff7f25115 <+21>:	sub    $0x100,%rsp
   0x00007ffff7f2511c <+28>:	data16 lea 0x5ad54(%rip),%rdi        # 0x7ffff7f7fe78
   0x00007ffff7f25124 <+36>:	data16 data16 rex.W call 0x7ffff7e82ab0 <__tls_get_addr@plt>
   0x00007ffff7f2512c <+44>:	lea    0x28(%rsp),%rdx
   0x00007ffff7f25131 <+49>:	mov    (%rax),%rax
   0x00007ffff7f25134 <+52>:	mov    %rax,(%rsp)
=> 0x00007ffff7f25138 <+56>:	mov    0x230(%rax),%rax
   0x00007ffff7f2513f <+63>:	mov    %rax,0x8(%rsp)
   0x00007ffff7f25144 <+68>:	sub    %rdx,%rax
   0x00007ffff7f25147 <+71>:	sar    $0x3,%rax
   0x00007ffff7f2514b <+75>:	cmp    0x5be7e(%rip),%rax        # 0x7ffff7f80fd0
   0x00007ffff7f25152 <+82>:	jbe    0x7ffff7f25165 <scm_call_n+101>
   0x00007ffff7f25154 <+84>:	mov    0x5ab45(%rip),%rax        # 0x7ffff7f7fca0

the code crashes in mov 0x230(%rax),%rax, because rax contains 0. It looks like this is the stack-checking code whith uses the current_thread.

if you experienced this before, or can straight tell me: don't do goroutines, as it cannot work, please do.
I'll go further with debugging as the alternative (littlescheme) is too small-featured.

regards

[jhelberg]

I'm using go 1.20 and guile 3.0 (2.2 has the same symptoms).

[jhelberg]

have a reproducable case now, doing the query is necessary, going through the rows as well. The code:

package main
import (
"log"
"fmt"
"os"
"database/sql"
_ "github.com/lib/pq"
"github.com/mrosset/scheme"
)
func main() {
var globalschemefuncs = []string{
"(define eerawrapper (lambda (res) (if (number? res) (number->string res) res)))",
"(define eeravars '())",
}
res, _ := scheme.Eval( "(version)" )
log.Printf( "Scheme version %s", res.String() )
dbinfo := fmt.Sprintf( "host=hh-pgsql-public.ebi.ac.uk port=5432 user=reader password=%s dbname=pfmegrnargs sslmode=disable",
"NWDMCE5xdipIjRrp" )
if db, err := sql.Open( "postgres", dbinfo ); err != nil {
log.Printf( "(%s) Error preparing connection to database, err: %v", os.Args[ 0 ], err )
return
} else {
defer db.Close()
if rows, err := db.Query( "SELECT upi, taxid, ac FROM xref WHERE ac IN ('OTTHUMT00000106564.1', 'OTTHUMT00000416802.1')" ); err != nil {
log.Printf( "(%s) Error running a query: %v", os.Args[ 0 ], err )
return
} else {
for rows.Next() {
}
}
}
for _, expr := range globalschemefuncs {
if _, err := scheme.Eval( expr ); err != nil {
log.Printf( "(%s) Error evaluating %s: %v", os.Args[0], expr, err )
}
}
i := 0
for i < 5000 {
scheme.Eval( (eerawrapper (set! eeravars (append eeravars '(("clock" . 1541768.762000))))) )
scheme.Eval( (eerawrapper (set! eeravars (append eeravars '(("accelerometer/z" . -0.050780))))))
scheme.Eval( (eerawrapper (set! eeravars (append eeravars '(("accelerometer/y" . -1.037360))))))
scheme.Eval( (eerawrapper (set! eeravars (append eeravars '(("accelerometer/x" . -0.038940))))))
scheme.Eval( (eerawrapper (set! eeravars '())) )
i += 1
log.Printf( "." )
}
}

running it gives:
$ ./crash
2023/03/27 10:02:31 Scheme version 3.0.7
SIGSEGV: segmentation violation
PC=0x7f3f53150138 m=5 sigcode=0
signal arrived during cgo execution

goroutine 1 [syscall]:
runtime.cgocall(0x5f7590, 0xc000197d78)
/usr/local/go/src/runtime/cgocall.go:157 +0x5c fp=0xc000197d50 sp=0xc000197d18 pc=0x406f9c
github.com/mrosset/scheme._Cfunc_scm_c_public_ref(0x188b450, 0x7f3f14000bd0)
_cgo_gotypes.go:130 +0x4d fp=0xc000197d78 sp=0xc000197d50 pc=0x5f606d
github.com/mrosset/scheme.Eval({0x65ea95?, 0x6b2f08?})
/media/usr/home/joost/go/src/github.com/mrosset/scheme/scheme.go:42 +0x9d fp=0xc000197e30 sp=0xc000197d78 pc=0x5f66bd
main.main()
/media/usr/home/joost/u/pm/proof4you/scripting/crash/schemecrash.go:33 +0x39e fp=0xc000197f80 sp=0xc000197e30 pc=0x5f72de
runtime.main()
/usr/local/go/src/runtime/proc.go:250 +0x207 fp=0xc000197fe0 sp=0xc000197f80 pc=0x439a67
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000197fe8 sp=0xc000197fe0 pc=0x467721

goroutine 2 [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000052fb0 sp=0xc000052f90 pc=0x439e96
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:387
runtime.forcegchelper()
/usr/local/go/src/runtime/proc.go:305 +0xb0 fp=0xc000052fe0 sp=0xc000052fb0 pc=0x439cd0
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000052fe8 sp=0xc000052fe0 pc=0x467721
created by runtime.init.6
/usr/local/go/src/runtime/proc.go:293 +0x25

goroutine 3 [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000053780 sp=0xc000053760 pc=0x439e96
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:387
runtime.bgsweep(0x0?)
/usr/local/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000537c8 sp=0xc000053780 pc=0x4265ee
runtime.gcenable.func1()
/usr/local/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000537e0 sp=0xc0000537c8 pc=0x41bac6
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000537e8 sp=0xc0000537e0 pc=0x467721
created by runtime.gcenable
/usr/local/go/src/runtime/mgc.go:178 +0x6b

goroutine 4 [GC scavenge wait]:
runtime.gopark(0xc00001c0e0?, 0x6af320?, 0x1?, 0x0?, 0x0?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000053f70 sp=0xc000053f50 pc=0x439e96
runtime.goparkunlock(...)
/usr/local/go/src/runtime/proc.go:387
runtime.(*scavengerState).park(0x7f51c0)
/usr/local/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc000053fa0 sp=0xc000053f70 pc=0x424533
runtime.bgscavenge(0x0?)
/usr/local/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc000053fc8 sp=0xc000053fa0 pc=0x424b05
runtime.gcenable.func2()
/usr/local/go/src/runtime/mgc.go:179 +0x26 fp=0xc000053fe0 sp=0xc000053fc8 pc=0x41ba66
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000053fe8 sp=0xc000053fe0 pc=0x467721
created by runtime.gcenable
/usr/local/go/src/runtime/mgc.go:179 +0xaa

goroutine 5 [finalizer wait]:
runtime.gopark(0x1a0?, 0x7f5780?, 0x60?, 0x78?, 0xc000052770?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000052628 sp=0xc000052608 pc=0x439e96
runtime.runfinq()
/usr/local/go/src/runtime/mfinal.go:193 +0x107 fp=0xc0000527e0 sp=0xc000052628 pc=0x41ab07
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000527e8 sp=0xc0000527e0 pc=0x467721
created by runtime.createfing
/usr/local/go/src/runtime/mfinal.go:163 +0x45

goroutine 6 [select]:
runtime.gopark(0xc000054788?, 0x2?, 0x8?, 0x7?, 0xc000054784?)
/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000054610 sp=0xc0000545f0 pc=0x439e96
runtime.selectgo(0xc000054788, 0xc000054780, 0x0?, 0x0, 0x0?, 0x1)
/usr/local/go/src/runtime/select.go:327 +0x7be fp=0xc000054750 sp=0xc000054610 pc=0x44965e
database/sql.(*DB).connectionOpener(0xc00010eb60, {0x6b2ed0, 0xc00007c0f0})
/usr/local/go/src/database/sql/sql.go:1218 +0x8d fp=0xc0000547b8 sp=0xc000054750 pc=0x4cdf6d
database/sql.OpenDB.func1()
/usr/local/go/src/database/sql/sql.go:791 +0x2e fp=0xc0000547e0 sp=0xc0000547b8 pc=0x4ccece
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000547e8 sp=0xc0000547e0 pc=0x467721
created by database/sql.OpenDB
/usr/local/go/src/database/sql/sql.go:791 +0x18d

rax 0x0
rbx 0x7f3f29ed0cf0
rcx 0x4
rdx 0x7f3f29ed0be8
rdi 0x7f3f531aae78
rsi 0x7f3f29ed0cf0
rbp 0x7f3f28510a40
rsp 0x7f3f29ed0bc0
r8 0x4
r9 0x0
r10 0x188b455
r11 0x4
r12 0x3
r13 0x7f3f285844e0
r14 0xc0000061a0
r15 0xc000088000
rip 0x7f3f53150138
rflags 0x10206
cs 0x33
fs 0x0
gs 0x0
$

[mrosset]

Thank you for reporting this. I apologize for the late reply. Most definitely this is probably a clash between guile threads and Go's green threads. I'll see if I can improve on this problem. Since it is possible to join guile threads.