[Bug go/114699] New: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[Bug go/114699] New: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

            Bug ID: 114699
           Summary: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete
                    so libraries crash when dlclosed
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: rjones at redhat dot com
  Target Milestone: ---

I was chasing a crash in nbdkit-golang-plugin
(https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/golang?ref_type=heads).

This crash only happens with gcc-go (and quite reproducibly), but doesn't
happen with golang.  The crash happened when the plugin was being unloaded
with dlclose(3).

Long story short, this is a bug that has already been reported and "fixed"
(or more accurately, worked around) in golang:

https://github.com/golang/go/issues/11100

Because goroutines, the garbage collector, etc is basically running all
the time in golang programs, you cannot safely remove them from memory.
Any attempt to actually dlclose a golang plugin will crash most of the
time when a goroutine/the GC executes some code after dlclose.

golang works around this by linking shared libraries it creates with
-Wl,-z,nodelete:

https://github.com/golang/go/blob/1843464f014c946c1663de76249267486887626f/src/cmd/link/internal/ld/lib.go#L1587

Because gcc-go doesn't do this, the same shared libraries crash when
compiled with it.

Fix (or workaround) is probably to copy what golang does.

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

--- Comment #1 from Richard W.M. Jones <rjones at redhat dot com> ---
gcc 14.0.1-0.13.fc40 => crashes
golang-bin-1.22.2-1.fc40.x86_64 => works

I also checked this by stracing the linking process and
seeing -Wl,-z,nodelete is being used by golang, but not by
gcc-go.

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

--- Comment #2 from Richard W.M. Jones <rjones at redhat dot com> ---
This was the stack trace of the crashing thread with gcc-go:

Thread 7 (Thread 0x7ff5c1af3a40 (LWP 2819340)):
#0  0x00007ff5c24d67cb in __GI_munmap () at
../sysdeps/unix/syscall-template.S:117
#1  0x00007ff5c24c916a in _dl_unmap_segments (l=0x563fc0eba080) at
./dl-unmap-segments.h:32
#2  _dl_unmap (map=map@entry=0x563fc0eba080) at ../sysdeps/x86_64/tlsdesc.c:31
#3  0x00007ff5c24b5ff5 in _dl_close_worker (map=<optimized out>,
map@entry=0x563fc0eb9a90, force=force@entry=false) at dl-close.c:628
#4  0x00007ff5c24b663b in _dl_close (_map=0x563fc0eb9a90) at dl-close.c:793
#5  0x00007ff5c24b5523 in __GI__dl_catch_exception
(exception=exception@entry=0x7fffe1bbd500, operate=0x7ff5c24b6600 <_dl_close>,
args=0x563fc0eb9a90) at dl-catch.c:237
#6  0x00007ff5c24b5679 in _dl_catch_error (objname=0x7fffe1bbd568,
errstring=0x7fffe1bbd570, mallocedp=0x7fffe1bbd567, operate=<optimized out>,
args=<optimized out>) at dl-catch.c:256
#7  0x00007ff5c20a4913 in _dlerror_run (operate=<optimized out>,
args=<optimized out>) at dlerror.c:138
#8  0x00007ff5c20a4656 in __dlclose (handle=<optimized out>) at dlclose.c:31
#9  0x0000563fb3951239 in backend_unload (b=b@entry=0x563fc0ebbf60,
unload=0x7ff5c1ae43b0) at /home/rjones/d/nbdkit/server/backend.c:154
#10 0x0000563fb39512bc in plugin_free (b=0x563fc0ebbf60) at
/home/rjones/d/nbdkit/server/plugins.c:64
#11 0x0000563fb394ed51 in main (argc=<optimized out>, argv=<optimized out>) at
/home/rjones/d/nbdkit/server/main.c:838

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

[rjones at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

--- Comment #3 from Richard W.M. Jones <rjones at redhat dot com> ---
(Edit comment 2: To be clear, that wasn't the thread where the
segfault occurred, which was some golang thread, that was the
thread that was unmapping the memory at the same time.  Using
nodelete avoids this by not actually unmapping the code.)