On 6/5/25 12:00 AM, Martin Gansser wrote:
[1] https://martinkg.fedorapeople.org/ErrorReports/gdb.txt
Thread 1 (Thread 0x7ffff69b9fc0 (LWP 201755) "speed-dreams-2"):
#0 0x00007fffad1687dc in ??? ()
#1 0x00007fffffffdb60 in ??? ()
#2 0x00007ffff7a90592 in _int_free (av=<optimized out>, p=<optimized out>,
have_lock=0) at malloc.c:4699
#3 __GI___libc_free (mem=<optimized out>) at malloc.c:3476
#4 0x00007fffad1688d5 in ??? ()
#5 0x00007fffffffdb70 in ??? ()
#6 0x000055555c60eb70 in ??? ()
#7 0x00007fffffffdb90 in ??? ()
#8 0x00007fffad191bb3 in ??? ()
#9 0x0000000000000000 in ??? ()
process 201755
cmdline = '/usr/bin/speed-dreams-2'
cwd = '/usr/share/games/speed-dreams-2'
exe = '/usr/bin/speed-dreams-2'
(gdb) shell cat /proc/201755/maps
Interpolating the return addresses from the traceback of Thread 1
into the page mappings, where the ranges have been indented
so that a constant-width font aligns numerical addresses
and makes it easier to search "by eye":
=====
55555555a000-55555fc62000 rw-p 00000000 00:00 0
[heap]
#6 0x000055555c60eb70 in ??? ()
=====
7fffac9f1000-7fffaca00000 rw-p 00000000 00:00 0
#0 0x00007fffad1687dc in ??? ()
#4 0x00007fffad1688d5 in ??? ()
#8 0x00007fffad191bb3 in ??? ()
7fffad3e3000-7fffad3e6000 r-xp 00000000 00:20 844051
/usr/lib64/libplibul.so.1.8.5
=====
7ffff7a0e000-7ffff7b7d000 r-xp 00000000 00:20 854664
/usr/lib64/libc.so.6
#2 0x00007ffff7a90592 in _int_free (av=<optimized out>, p=<optimized
out>, have_lock=0) at malloc.c:4699
=====
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
#1 0x00007fffffffdb60 in ??? ()
#5 0x00007fffffffdb70 in ??? ()
#7 0x00007fffffffdb90 in ??? ()
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0
[stack]
=====
shows that most of the return addresses have no page mapping.
Assuming that the traceback is valid, then the return addresses
have been unmapped after they were written by a CALL instruction.
Unmapping can occur by explicit munmap(), explicit dlclose(),
or destruction of a thread. Return address #6 (0x000055555c60eb70)
is inside a heap region, which suggests code generation at runtime.
Gdb comments show the exiting of 14 threads [snipped]. If an active
return address belongs to an exited thread, then that's bad,
and similarly remembering any address of on-stack local storage
from an exited thread is a programming error. Do such events
seem to be related to the code of the app (speed-dreams-2)?
Because the page mappings at the time of the SIGSEGV seem strange,
then detailed watching of the page mapping may give clues. Try:
strace -f -o strace.out -e trace=memory speed-dreams-2
and then detailed matching of addresses into the indicated ranges.
(This tends to be tedious.)
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
