[Comm] Падение программы под 2.6.3x

[Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

Здравствуйте!

Случилась такая проблема: есть некая программы, которая компилируется без 
ошибок, при этом нормально работает под ядрами 2.6.2x (альт 4.x), но падает 
под 2.6.3x (p5). Причём и то и другое поведение проверено на двух 
компьютерах: в первом случае --- Десктопы 4.0. и 4.1, а во втором --- 
АркСервер и  какой-то из 5-х десктопов (его сейчас нет под рукой --- точную 
версию не знаю). Падает так:

$ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
 > *** stack smashing detected ***: ../BIN/bin2sac terminated
 > ======= Backtrace: =========
 > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]
 > /lib/libc.so.6(+0xde05a)[0xb771105a]
 > ../BIN/bin2sac[0x8048e06]
 > /lib/libc.so.6(__libc_start_main+0xe6)[0xb7649c66]
 > ../BIN/bin2sac[0x8048731]
 > ======= Memory map: ========
 > 08048000-0804b000 r-xp 00000000 09:03 8345
 > /var/srv/home/karp/MTPACKAGE/BIN/bin2sac
 > 0804b000-0804c000 r-xp 00002000 09:03 8345
 > /var/srv/home/karp/MTPACKAGE/BIN/bin2sac
 > 0804c000-0804d000 rwxp 00003000 09:03 8345
 > /var/srv/home/karp/MTPACKAGE/BIN/bin2sac
 > 0804d000-0806e000 rwxp 00000000 00:00 0 [heap]
 > b7613000-b7630000 r-xp 00000000 09:01 60881 /lib/libgcc_s.so.1
 > b7630000-b7631000 r-xp 0001c000 09:01 60881 /lib/libgcc_s.so.1
 > b7631000-b7632000 rwxp 0001d000 09:01 60881 /lib/libgcc_s.so.1
 > b7632000-b7633000 rwxp 00000000 00:00 0
 > b7633000-b7785000 r-xp 00000000 09:01 58278 /lib/libc-2.11.2.so
 > b7785000-b7787000 r-xp 00152000 09:01 58278 /lib/libc-2.11.2.so
 > b7787000-b7788000 rwxp 00154000 09:01 58278 /lib/libc-2.11.2.so
 > b7788000-b778b000 rwxp 00000000 00:00 0
 > b7794000-b7795000 rwxp 00000000 00:00 0
 > b7795000-b7796000 r-xp 00000000 00:00 0 [vdso]
 > b7796000-b77b1000 r-xp 00000000 09:01 58014 /lib/ld-2.11.2.so
 > b77b1000-b77b2000 r-xp 0001b000 09:01 58014 /lib/ld-2.11.2.so
 > b77b2000-b77b3000 rwxp 0001c000 09:01 58014 /lib/ld-2.11.2.so
 > bfc9f000-bfcb4000 rw-p 00000000 00:00 0 [stack]

Я не программист чтобы в этом разобраться, более того, автор тоже ничего 
толком сказать не может. Единственно, что он смог сказать, что у него под 
Федорой 14 эта программа, скомпилированная gcc 4.5.1, работает нормально, а 
скомпилировать её gcc весий 3.3.2, 3.3.9 и 4.1.2 он без ошибок не смог. В 
p5 gcc 4.5.1 нет, поэтому проверить, является ли это проблемой gcc я не 
могу. В среду-четверг попробую загрузиться на том же компьютере с ядром 
помладше, чтобы проверить зависимость именно от ядра.

На что ещё стоит обратить внимание, какие тесты провести? Программа очень 
нужна, буду благодарен за любые советы.

-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[Damir]

> Случилась такая проблема: есть некая программы, которая компилируется без
> ошибок, при этом нормально работает под ядрами 2.6.2x (альт 4.x), но падает
> под 2.6.3x (p5). Причём и то и другое поведение проверено на двух
> компьютерах: в первом случае --- Десктопы 4.0. и 4.1, а во втором ---
> АркСервер и  какой-то из 5-х десктопов (его сейчас нет под рукой --- точную
> версию не знаю). Падает так:
> Я не программист чтобы в этом разобраться, более того, автор тоже ничего
> толком сказать не может. Единственно, что он смог сказать, что у него под
> Федорой 14 эта программа, скомпилированная gcc 4.5.1, работает нормально, а
> скомпилировать её gcc весий 3.3.2, 3.3.9 и 4.1.2 он без ошибок не смог. В p5
> gcc 4.5.1 нет, поэтому проверить, является ли это проблемой gcc я не могу. В
> среду-четверг попробую загрузиться на том же компьютере с ядром помладше,
> чтобы проверить зависимость именно от ядра.
>
> На что ещё стоит обратить внимание, какие тесты провести? Программа очень
> нужна, буду благодарен за любые советы.

Попробуйте запуститься под valgrind-ом, может он более развернутую
информацию покажет.

apt-get install valgrind

valgrind -v ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss

Ну и программу желательно собрать с отладочной информацией.

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

28.02.2011 11:30, Damir пишет:
> Попробуйте запуститься под valgrind-ом, может он более развернутую
> информацию покажет.

Он действительно дал развёрнутую информацию, но она для меня --- "тёмный лес"

-- 
	С уважением,
		Владимир.


[-- Attachment #2: valgrind.log.bz2 --]
[-- Type: application/octet-stream, Size: 2536 bytes --]

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 14:15, Vladimir Karpinsky пишет:
> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>  > *** stack smashing detected ***: ../BIN/bin2sac terminated
>  > ======= Backtrace: =========
>  > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]

> На что ещё стоит обратить внимание, какие тесты провести? Программа
> очень нужна, буду благодарен за любые советы.

Попробуйте задать флаг препроцессора -U_FORTIFY_SOURCE

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

28.02.2011 11:38, REAL пишет:
> 28.02.2011 14:15, Vladimir Karpinsky пишет:
>> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>> > *** stack smashing detected ***: ../BIN/bin2sac terminated
>> > ======= Backtrace: =========
>> > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]
>
>> На что ещё стоит обратить внимание, какие тесты провести? Программа
>> очень нужна, буду благодарен за любые советы.
>
> Попробуйте задать флаг препроцессора -U_FORTIFY_SOURCE

То же самое.

Обратил сейчас внимание на различия при компиляции:

4.1, gcc 4.1

$  make
cc sac2helm.c -c
cc getpar.c -c
...



p5, gcc 4.4

$  make
cc sac2helm.c -c
cc getpar.c -c
getpar.c: In function ‘getpar’:
getpar.c:518: warning: format ‘%s’ expects type ‘char *’, but argument 3 
has type ‘int *’
...

Здесь не могла собака порыться?


-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 15:16, Vladimir Karpinsky пишет:
>>> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>>> > *** stack smashing detected ***: ../BIN/bin2sac terminated
>>> > ======= Backtrace: =========
>>> > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]
>>
>>> На что ещё стоит обратить внимание, какие тесты провести? Программа
>>> очень нужна, буду благодарен за любые советы.
>>
>> Попробуйте задать флаг препроцессора -U_FORTIFY_SOURCE
>
> То же самое.

Дайте url на исходники.

> $ make
> cc sac2helm.c -c
> cc getpar.c -c
> getpar.c: In function ‘getpar’:
> getpar.c:518: warning: format ‘%s’ expects type ‘char *’, but argument
> 3 has type ‘int *’
>
> Здесь не могла собака порыться?

Вряд ли, хотя кто знает...

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

28.02.2011 12:36, REAL пишет:
> Дайте url на исходники.

http://plkv.gsras.ru/~karp/mtpackage.tar.gz

Дальше я пытаюсь выполнить процедуру, описанную в example2/readme.

-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

On Mon, Feb 28, 2011 at 12:44:38PM +0300, Vladimir Karpinsky wrote:
> 28.02.2011 12:36, REAL пишет:
> > Дайте url на исходники.
> 
> http://plkv.gsras.ru/~karp/mtpackage.tar.gz
> 
> Дальше я пытаюсь выполнить процедуру, описанную в example2/readme.

make CFLAGS="-g -O2" немедленно указывает на место ошибки:

cc bin2sac.c -c -g -O2  
In file included from /usr/include/stdio.h:912:0,
                 from bin2sac.c:2:
In function ‘sprintf’,
    inlined from ‘main’ at bin2sac.c:20:8:
/usr/include/bits/stdio2.h:34:3: error: call to __builtin___sprintf_chk will always overflow destination buffer
In function ‘sprintf’,
    inlined from ‘main’ at bin2sac.c:21:8:
/usr/include/bits/stdio2.h:34:3: error: call to __builtin___sprintf_chk will always overflow destination buffer
make: *** [bin2sac.o] Ошибка 1


 char chd[8][24], ename[16], sname[8];
...
for(i=0;i<8;i++)  sprintf(chd[i],"-12345  -12345  -12345  ");
sprintf(ename,"-12345  -12345  ");
sprintf(sname,"-12345  ");
...
sprintf(chd[0],"%-8s%-16s",sname,ename);

При выделении места под строки забыли про завершающий '\0'.

Затычка:

--- bin2sac.c.orig	2011-02-09 04:16:23.000000000 +0300
+++ bin2sac.c	2011-02-28 21:24:11.179999993 +0300
@@ -10,7 +10,7 @@ main(ac,av)
  int i, npts, year, jday, hour, min, sec, msec, ihd[40];
  float dt, B=0.0, E, fhd[70], *tr, evla, evlo, stla, stlo, dist;
  float azi, bazi, cmpaz, cmpinc;
- char chd[8][24], ename[16], sname[8];
+ char chd[8+1][24], ename[16+1], sname[8+1];
 
 
 /* Initialize Header */


Однако это не избавляет от попадания '\0' в chd[1][0] после выполнения
sprintf(chd[0],"%-8s%-16s",sname,ename); - это лечится только
переписыванием кода, как и возможность переполнения буферов ename и
sname в случае неверных входных данных.

К сожалению, такие переполнения буферов в стеке (на 1 байт) valgrind
не ловит - срабатывает только проверка при возврате из функции,
включаемая опцией -fstack-protector (в ALT эта опция включена по
умолчанию), когда уже сложно установить, в каком именно месте функции
произошло переполнение буфера.  Однако при включении оптимизации (-O2)
начинает работать опция -D_FORTIFY_SOURCE=2 (также используется в ALT
по умолчанию); в данном случае проблема обнаруживается ещё при
компиляции, в других случаях возможен аварийный останов при
выполнении.

Добавление exit(0) просто отключает проверку при возврате из main(),
поскольку этот возврат уже не выполняется.  Лучше вместо этого
написать хотя бы return 0 (о проверке результатов write() в данном
случае, похоже, мечтать уже не приходится).

Ну и стоило бы ткнуть авторов носом в результаты сборки с
CFLAGS="-g -O2 -Wall -W" - наличие предупреждений вида warning:
'quiet' is used uninitialized in this function (даже не may be used
uninitialized, а именно is used uninitialized) не внушает уверенности
в правильности работы этого кода.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

28.02.2011 21:46, Sergey Vlasov пишет:
> make CFLAGS="-g -O2" немедленно указывает на место ошибки:
...

Спасибо! Теперь мне надо как-то это перевести на английский, да так чтобы 
втолковать авторам. Буду пробовать...

К сожалению даже это не всё. Судя по всему они ещё где-то с математикой 
накосячили, потому что ответ не сходится :-(. Ничего умнее, как 
скомпилировать gcc 4.5.1 посоветовать не могут --- мол только с этим 
компилятором у них всё хорошо. Вопрос следующий: насколько я вижу 4.5.1 
есть только в Сизифе, насколько сложно его оттуда поставить, много ли 
потянет, надо ли пересобирать?

-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 15:36, REAL пишет:
> 28.02.2011 15:16, Vladimir Karpinsky пишет:
>>>> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>>>> > *** stack smashing detected ***: ../BIN/bin2sac terminated
>>>> > ======= Backtrace: =========
>>>> > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]

Скачал файл, сделал ему make, перешёл в example2, ошибок нет. В файле 
tss собрались всяческие бинарные данные.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

28.02.2011 13:08, REAL пишет:
> 28.02.2011 15:36, REAL пишет:
>> 28.02.2011 15:16, Vladimir Karpinsky пишет:
>>>>> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>>>>> > *** stack smashing detected ***: ../BIN/bin2sac terminated
>>>>> > ======= Backtrace: =========
>>>>> > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]
>
> Скачал файл, сделал ему make, перешёл в example2, ошибок нет. В файле tss
> собрались всяческие бинарные данные.

"Всё страньше и страньше" (с).

Пойдём с другой стороны: может ли моя проблема вылезти из слобосильности 
компьютеров? В обоих случаях, где я наблюдаю проблемы стоят компьютеры с 
0.5Гб оперативной памяти, с процессором Sempron или Celeron, т.е. оба 
процессора слегка неполноценные. Это, конечно, странно, но я теперь совсем 
не понимаю за что хвататься...

Если нетрудно, выложите, пожалуйста куда-нибудь получившиеся бинарники (или 
в личку).


-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 16:31, Vladimir Karpinsky пишет:
>>>>>> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>>>>>> > *** stack smashing detected ***: ../BIN/bin2sac terminated
>>>>>> > ======= Backtrace: =========
>>>>>> > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]
>>
>> Скачал файл, сделал ему make, перешёл в example2, ошибок нет. В
>> файле tss
>> собрались всяческие бинарные данные.
>
> "Всё страньше и страньше" (с).
>
> Пойдём с другой стороны: может ли моя проблема вылезти из
> слобосильности компьютеров?

Не, это я на автомате добавил недостающее, и как-то сразу забыл 
(сейчас со всех сторон моего внимания требуют).

В общем, попробуйте в конец функции main добавить exit(0);
потом make
потом пробуйте пример

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 17:37, REAL пишет:
> Не, это я на автомате добавил недостающее, и как-то сразу забыл
> (сейчас со всех сторон моего внимания требуют).
>
> В общем, попробуйте в конец функции main добавить exit(0);

Речь про bin2sac.c

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

28.02.2011 14:37, REAL пишет:
> 28.02.2011 16:31, Vladimir Karpinsky пишет:
>>>>>>> $ ../BIN/bin2sac par=./b2s.par npts=1024 dt=0.05 < tmp3 > tss
>>>>>>> > *** stack smashing detected ***: ../BIN/bin2sac terminated
>>>>>>> > ======= Backtrace: =========
>>>>>>> > /lib/libc.so.6(__fortify_fail+0x40)[0xb77110a0]
>>>
>>> Скачал файл, сделал ему make, перешёл в example2, ошибок нет. В
>>> файле tss
>>> собрались всяческие бинарные данные.
>>
> Не, это я на автомате добавил недостающее, и как-то сразу забыл (сейчас со
> всех сторон моего внимания требуют).
>
> В общем, попробуйте в конец функции main добавить exit(0);
> потом make
> потом пробуйте пример

Спасибо! Я бы с этим до конца дней своих бы ковырялся...

Действительно вылет не случился, сейчас со смыслом результата буду 
разбираться. Пока вижу, что Файлы tss получились в обоих случаях идентичными.

Вопрос на будущее: почему в разных системах ЭТО обрабатывается по-разному? 
Повторюсь я не программист, поэтому не в курсе, но хотелось бы понять: 
отсутствие exit --- это ошибка? Почему она проявляется в одних условиях, и 
не проявляется в других?

Ещё раз огромное спасибо!

-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 18:04, Vladimir Karpinsky пишет:
> Действительно вылет не случился, сейчас со смыслом результата буду
> разбираться. Пока вижу, что Файлы tss получились в обоих случаях
> идентичными.
>
> Вопрос на будущее: почему в разных системах ЭТО обрабатывается
> по-разному?

Это уже к создателям программы.


> Повторюсь я не программист, поэтому не в курсе, но
> хотелось бы понять: отсутствие exit --- это ошибка? Почему она
> проявляется в одних условиях, и не проявляется в других?

Программа должна корректно завершаться, а это exit. Без него приходит 
злобный segfault. А если функция не main, тогда exit нужно 
использовать осторожно, если это действительно нужно (например, ошибка 
в самой программе, и тут её нужно лечить).

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[Vladimir Karpinsky]

28.02.2011 15:55, REAL пишет:
> 28.02.2011 18:04, Vladimir Karpinsky пишет:
>> Вопрос на будущее: почему в разных системах ЭТО обрабатывается
>> по-разному?
>
> Это уже к создателям программы.

Это я им отпишу, конечно.

>> Повторюсь я не программист, поэтому не в курсе, но
>> хотелось бы понять: отсутствие exit --- это ошибка? Почему она
>> проявляется в одних условиях, и не проявляется в других?
>
> Программа должна корректно завершаться, а это exit. Без него приходит
> злобный segfault. А если функция не main, тогда exit нужно использовать
> осторожно, если это действительно нужно (например, ошибка в самой
> программе, и тут её нужно лечить).

Понятно, т.е. имеется явная ошибка программиста.

А насчёт разного поведения на разных ядрах: правильно ли я понимаю, что на 
более новых ядрах таким образом усилена защита от возможного segfault'а?

-- 
	С уважением,
		Владимир.

Re: [Comm] Падение программы под 2.6.3x

[REAL]

28.02.2011 19:01, Vladimir Karpinsky пишет:
>> Программа должна корректно завершаться, а это exit. Без него приходит
>> злобный segfault. А если функция не main, тогда exit нужно использовать
>> осторожно, если это действительно нужно (например, ошибка в самой
>> программе, и тут её нужно лечить).
>
> Понятно, т.е. имеется явная ошибка программиста.

да. код возврата отличный от 0 имеет смысл при использовании в 
shell-скриптах. в иных случаях нужно в консерватории дезинфекцию 
проводить.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Падение программы под 2.6.3x

[Yura Kalinichenko]

REAL пишет:
>
> Программа должна корректно завершаться, а это exit. 
Неправда. Программа не обязана явно завершаться exit(). Имеется 
рекомендация завершать по return(0), но она не обязательна. См., напр., 
Википедия "Си (язык программирования)"
> Без него приходит злобный segfault. 
Если он приходит по выходу - скорее всего накосячено было раньше где-то 
со стеками/буферами/кучами. А это - лишь симптом болезни, лечить надо в 
другом месте.

-- 
SY, 
   Yura Kalinichenko

Re: [Comm] Падение программы под 2.6.3x

[Damir]

> Обратил сейчас внимание на различия при компиляции:
>
> 4.1, gcc 4.1
>
> $  make
> cc sac2helm.c -c
> cc getpar.c -c
> ...
>
>
>
> p5, gcc 4.4
>
> $  make
> cc sac2helm.c -c
> cc getpar.c -c
> getpar.c: In function ‘getpar’:
> getpar.c:518: warning: format ‘%s’ expects type ‘char *’, but argument 3 has
> type ‘int *’
> ...
>
> Здесь не могла собака порыться?

Вполне могла, смотря куда пишется этот самый printf - если
используется что-то вроде sprintf, то вполне может и переполнение
буфера произойти.