Ich habe sporadische, nicht reproduziere Crashs vom VDR beim Speichern der channel.conf, mit mir nicht wirklich hilfreichen Backtraces (unaligned fastbin chunk detected).
Um dies weiter einzugrenzen habe ich VDR mal mit "-fsanitize=address" gebaut.
Damit bekome ich kurz nach dem Start vom VDR reproduzierbar einen Abruch wegen "heap-use-after-free".
=================================================================
==217722==ERROR: AddressSanitizer: heap-use-after-free on address 0x51b00067a990 at pc 0x559fd58f6edc bp 0x7ffdba58bab0 sp 0x7ffdba58baa0
READ of size 8 at 0x51b00067a990 thread T0
#0 0x559fd58f6edb in cListObject::Next() const /usr/src/vdr/vdr/tools.h:560
#1 0x559fd58f6edb in cList<cScanData>::Next(cScanData const*) const /usr/src/vdr/vdr/tools.h:663
#2 0x559fd58f6edb in cList<cScanData>::Next(cScanData const*) /usr/src/vdr/vdr/tools.h:674
#3 0x559fd58f6edb in cEITScanner::Process() /usr/src/vdr/vdr/eitscan.c:150
#4 0x559fd5851980 in main /usr/src/vdr/vdr/vdr.c:1521
#5 0x7f91294c91c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#6 0x7f91294c928a in __libc_start_main_impl ../csu/libc-start.c:360
#7 0x559fd58572d4 in _start (/usr/bin/vdr+0x1092d4) (BuildId: c96b8e9629fda30857fe4287244e7b02d1296894)
0x51b00067a990 is located 16 bytes inside of 1624-byte region [0x51b00067a980,0x51b00067afd8)
freed by thread T0 here:
#0 0x7f9129dd0738 in operator delete(void*, unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:164
#1 0x559fd5aa5493 in cListBase::Del(cListObject*, bool) /usr/src/vdr/vdr/tools.c:2257
previously allocated by thread T0 here:
#0 0x7f9129dcf698 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:95
#1 0x559fd58f63c9 in cScanList::AddTransponder(cChannel const*) /usr/src/vdr/vdr/eitscan.c:66
SUMMARY: AddressSanitizer: heap-use-after-free /usr/src/vdr/vdr/tools.h:560 in cListObject::Next() const
Shadow bytes around the buggy address:
0x51b00067a700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x51b00067a780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x51b00067a800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x51b00067a880: 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa
0x51b00067a900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x51b00067a980: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
0x51b00067aa00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x51b00067aa80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x51b00067ab00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x51b00067ab80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x51b00067ac00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==217722==ABORTING
Display More
Wenn ich die Commits schrittweise zurück gehe, wird das Problem mit diesem Commit eingeführt.
kls Kann es sein, dass das Objekt, das mit "scanList->Del(ScanData);" gelöscht wird, vom EIT Scanner weiter verwendet wird ? Leider verstehe ich den Teil nicht gut genug, um einen Patch zu schreiben.
Ob das Problem was mit meinem ursprüngichen Problem zu tun hat, ist auch nicht sicher, aber ein gelöschtes Objekt zu beschreiben kann alle möglichen Effekte haben.