Сегодня мне пришел баг-репорт от пользователя Debian, который скормил какую-то ерунду в утилиту scdoc и получил SIGSEGV. Исследование проблемы позволило мне провести отличное сравнение между musl libc и glibc. Для начала посмотрим на стектрейс:
==26267==ERROR: AddressSanitizer: SEGV on unknown address 0x7f9925764184
(pc 0x0000004c5d4d bp 0x000000000002 sp 0x7ffe7f8574d0 T0)
==26267==The signal is caused by a READ memory access.
0 0x4c5d4d in parse_text /scdoc/src/main.c:223:61
1 0x4c476c in parse_document /scdoc/src/main.c
2 0x4c3544 in main /scdoc/src/main.c:763:2
3 0x7f99252ab0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
4 0x41b3fd in _start (/scdoc/scdoc+0x41b3fd)
В исходниках на данной строчке написано вот что:
if (!isalnum(last) || ((p->flags & FORMAT_UNDERLINE) && !isalnum(next))) {
Подсказка: p — это корректный, ненулевой указатель. Переменные last и next имеют тип uint32_t. Сегфолт случается на втором вызове функции isalnum. И, самое важное: воспроизводится только при использовании glibc, но не musl libc. Если вам пришлось перечитать код несколько раз, вы не одиноки: тут попросту нечему вызывать сегфолт.Читать полностью »
