Bug 2269887

Created attachment 2021990 [details]
File: mountinfo

Created attachment 2021991 [details]
File: environ

Created attachment 2021992 [details]
File: core_backtrace

Created attachment 2021993 [details]
File: backtrace

Created attachment 2021994 [details]
File: limits

Created attachment 2021995 [details]
File: proc_pid_status

Created attachment 2021996 [details]
File: cpuinfo

Created attachment 2021997 [details]
File: os_info

Created attachment 2021998 [details]
File: dso_list

Created attachment 2021999 [details]
File: maps

Created attachment 2022000 [details]
File: open_fds

it looks like cscope was killed by SIGABRT, presumably, at container exit. cscope itself looks ok.

> abort() is usually called by library functions which detect an internal error or some seriously
> broken constraint. For example malloc() will call abort() if its internal structures are damaged
> by a heap overflow.

> container exit

I'm not sure what you mean by "container", but just in case: this was being run via an interactive shell on the base OS (no docker, etc. involved).

*** Bug 2256515 has been marked as a duplicate of this bug. ***

so a research shows that the cscope process attempted a normal exit (by "q" or Ctrl-D) calling myexit(0).
in the middle of it a signal SIGHUP handler was called, which is myexit() itself. then glibc detects a
double-free condition in __GI___libc_free() while performing fclose(refsfound). then glibc aborts the process
with __GI_abort() and the "free(): double free detected in tcache 2" message. backtraces we have are:

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1079 in myexit(sig=0): freefilelist(); ->
    dir.c:727 in in freefilelist(): free(srcfiles[--nsrcfiles]); ->
      malloc.c:3352 in __GI___libc_free() ->
        <signal handler called> ->
          main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
            iofclose.c:74 in _IO_new_fclose() -> ... ->
              malloc.c:3391 in __GI___libc_free() ->
                malloc_printerr("free(): double free detected in tcache 2") -> __GI_abort()

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1066 in myexit(sig=0): unlink(temp1); ->
    unlink.c:28 __unlink (name=<temp1> "/tmp/cscope.699047/cscope.1"); ->
      <signal handler called> ->
        main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
          iofclose.c:74 in _IO_new_fclose() -> ... ->
            malloc.c:3391 in __GI___libc_free() ->
              malloc_printerr("free(): double free detected in tcache 2") -> __GI_abort()

in a short word, a process abort is caused by myexit() interrupted by a signal which handler is myexit() itself. 

note, free() and fclose() are NOT async-signal-safe, see "man 7 signal-safety". calling an async-signal-unsafe
function from a signal handler is perfectly legal unless the signal interrupted another async-signal-unsafe function.
so i'm not sure about the unlink() case, unlink() is async-signal-safe. still, the double-free condition is still
there, as we can see from the backtrace.

i'm not going to fix the whole signal handling in cscope, as it is broken. 1) myexit() calls functions which are
not async-signal-safe 2) signal() infrastructure (which is broken) is used instead of sigaction(). i'll fix only
this specific case where myexit() is interrupted by a call to myexit() itself by resetting signal handlers to
default ones. this may be not entirely correct but whatever.

a fix: https://src.fedoraproject.org/rpms/cscope/c/a4d105ed18317c43e41fd20934509f8f250edc68?branch=rawhide
reported upstream: https://sourceforge.net/p/cscope/mailman/message/58802909/

the updates were pushed:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0429a348fa
https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd9f88a9af
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b787cf0ab9