This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/23616] New: Unknown signal error from gdb when stepping over musl libc function call using SIGSYNCCALL


https://sourceware.org/bugzilla/show_bug.cgi?id=23616

            Bug ID: 23616
           Summary: Unknown signal error from gdb when stepping over musl
                    libc function call using SIGSYNCCALL
           Product: gdb
           Version: 8.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: valianopub at gmail dot com
  Target Milestone: ---

In applications linked against musl libc, stepping over calls to the
'setrlimit' library function result with an error from gdb:

    Thread 1 "myprog" recieved signal ?, Unknown signal.
    __cp_end () at src/thread/x86_64/syscall_cp.s:29

Then, it's not possible to continue the debug session beyond that point.

This issue was seen on Alpine Linux, but may be applicable to apps linked
against musl libc on other Linux distros as well. Specifically, it is seen when
debugging certain versions of OpenJDK and CoreCLR (links 1, 2) (in which the
issue is especially troubling since setrlimit is called during VM startup).

The issue stems from the musl libc implementation of setrlimit (link 3). It
updates threads in a synchronized manner by calling __synccall (link 4), which
signals the threads with a SIGSYNCCALL signal:

    r = -__syscall(SYS_tgkill, pid, tid, SIGSYNCCALL);

SIGSYNCCALL is internal to musl and doesn't seem to be recognized by gdb. When
stepping over this code line, gdb intercepts the SIGSYNCCALL signal and reports
the "Unknown signal" error.

This signal is defined as follows in musl pthread_impl.h (link 5), along with
two other signal types:

    #define SIGTIMER 32
    #define SIGCANCEL 33
    #define SIGSYNCCALL 34

Adding support for these signal types in gdb, at least avoiding the mentioned
error, will enable better debugging of OpenJDK and other apps on Alpine Linux.

Tested with:
- Alpine Linux V3.8
- OpenJDK (openjdk7 / openjdk8 package, but any OpenJDK version should be
applicable)
- gdb versions 8.0.1-r6, 8.0.1-r3, 7.12.1-r1.

Reproduction:
- gdb <path/to/java>
- r -version

Links:

[1] https://github.com/dotnet/coreclr/issues/7487
[2]
https://stackoverflow.com/questions/52119176/gdb-debugging-openjdk-java-on-alpine-linux-fails-with-thread-recieved-signal
[3] http://git.musl-libc.org/cgit/musl/tree/src/misc/setrlimit.c
[4] http://git.musl-libc.org/cgit/musl/tree/src/thread/synccall.c
[5] http://git.musl-libc.org/cgit/musl/tree/src/internal/pthread_impl.h

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]