Может ли Valgrind влиять на выполнение программы?

@margosh · Регистрация: 15.05.2012

Студворк — интернет-сервис помощи студентам

Всем добрый день!
Столкнулась со следующим : при запуске программы под Valgrind(Memcheck) функция sigpromask() завершается с ошибкой, в то время как при обычном запуске - работает нормально. Каким образом Valgrind может влиять на работу данной функции, и как исправить это досадное недоразумение?

g_u_e_s_t · 21.06.2012, 12:21

Сообщение от margosh

Каким образом Valgrind может влиять на работу данной функции, и как исправить это досадное недоразумение?

Вообще не должен никак влиять на результат вызова. Ф-ция перехватывается, маска изменяется , а how (1й парамер) не трогают. Т.е. ну не должно оно никак влиять...
Ошибка EINVAL или EFAULT? Какой сискол в итоге используется sys_sigprocmask или sys_rt_sigprocmask?

@margosh · 25.06.2012, 14:56 **[ТС]**

@g_u_e_s_t, спасибо, Вы навели меня на мысль, в какую сторону копать.
Более-менее разобралась : Valgrind-у не давал покоя как раз параметр "how" - несмотря на то, что это чтение маски, а не запись, он анализировался. Я по примеру из книжки передала в качестве этого параметра 0, без Valgrind работало нормально, с ним - нет. Я бы не прочь узнать природу ошибки, однако Valgrind завершал работу еще до печати сообщения из обработчика ошибки, и сам номер не выводил. Возможно, требуются какие-то допопции...

Вобщем, я поменяла аргумент "how" с 0 на SIG_UNBLOCK, и программа продолжила выполнение под Valgrind, как и предполагалось.

g_u_e_s_t · 25.06.2012, 17:44

C
1
2
3
4
5
6
7
8
9
10
11
12
int
main(void)
{
        sigset_t set;
 
        system("uname -a");
        printf("SIG_BLOCK = %d, SIG_UNBLOCK = %d, SIG_SETMASK = %d.\n",
            SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK);
        if (sigprocmask(5, NULL, &set))
                err(1, "sigprocmask");
        return (0);
}

Bash
1
2
3
4
5
6
==1689== Command: ./sigprocmask
==1689==
Linux debian 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
SIG_BLOCK = 0, SIG_UNBLOCK = 1, SIG_SETMASK = 2.
--1689-- sigprocmask: unknown 'how' field 5
sigprocmask: sigprocmask: Invalid argument

Т.е. у меня valgrind явно ругается. А у Вас, как я понял, тишина. Странно это все

Вобщем, я поменяла аргумент "how" с 0 на SIG_UNBLOCK, и программа продолжила выполнение под Valgrind, как и предполагалось.

Дело происходит на какой-то редкой платформе? На интел, амд и арм эти константы как раз с нуля начинаются.

@margosh · 26.06.2012, 13:41 **[ТС]**

Т.е. у меня valgrind явно ругается. А у Вас, как я понял, тишина. Странно это все

да нет, это я упустила сходу от удивления, что программа завершилась так быстро, потом внимательнее посмотрела на сообщения от Valgrind и разобралась (я первый раз с valgrind работаю, пытаюсь освоить)

Дело происходит на какой-то редкой платформе? На интел, амд и арм эти константы как раз с нуля начинаются.

нет, все тот же Интел. может конечно ОС какие-то ограничения накладывает...

Добавлено через 2 часа 21 минуту
Есть еще вопрос : как под Valgrind завершить работу демона? Т.е., я так понимаю, обычная программа поработает, штатно завершится, и Valgrind выводит по ней статистику. Мой демон завершается при получении sigterm, однако, если послать ему сигнал, когда он под Valgrind-ом, вылезают не только утечки, но и SIGSEGV, которого при запуске и завершении без Valgrind не было.

g_u_e_s_t · 27.06.2012, 10:06

Сообщение от margosh

нет, все тот же Интел. может конечно ОС какие-то ограничения накладывает...

Совсем странно. Может покажите как valgrind ругается "sigprocmask: unknown 'how' field 0", uname -a и версию valgrind?

Сообщение от margosh

Есть еще вопрос : как под Valgrind завершить работу демона?

Как и без него.

Сообщение от margosh

Т.е., я так понимаю, обычная программа поработает, штатно завершится, и Valgrind выводит по ней статистику

Да. Еще можно снять статистику не завершая работы.
запускаем valgrind с ключиками --vgdb=yes --vgdb-error=0, в нужный момент подцепить gdb и сказать valgrind снять статистику, подробности в документации

Сообщение от margosh

Мой демон завершается при получении sigterm, однако, если послать ему сигнал, когда он под Valgrind-ом, вылезают не только утечки, но и SIGSEGV, которого при запуске и завершении без Valgrind не было.

Это не нормально, как и Ваша 1я проблема. Вероятно ошибки/вольности в обработчике SIGTERM или в коде завершения демона.

@margosh · 27.06.2012, 11:18 **[ТС]**

Совсем странно. Может покажите как valgrind ругается "sigprocmask: unknown 'how' field 0", uname -a и версию valgrind?

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
# 
==60907== 
--60907-- Valgrind options:
--60907--    --leak-check=full
--60907--    --track-origins=yes
--60907--    --num-callers=30
--60907--    -v
--60907-- Contents of /proc/version:
--60907-- Arch and hwcaps: X86, x86-sse1-sse2
--60907-- Page sizes: currently 4096, max supported 4096
--60907-- Valgrind library directory: /usr/local/lib/valgrind
--60907-- Reading syms from /libexec/ld-elf.so.1 (0x10000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/local/fnp/sbin/fnp_shd (0x8048000)
--60907-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--60907-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-x86-freebsd.so (0x57000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so (0x59000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/local/fnp/lib/libfnp.so.3 (0x61000)
--60907-- Reading syms from /usr/local/lib/libfnpcrypt.so.3 (0xe3000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/local/lib/libintl.so.9 (0x100000)
--60907-- Reading syms from /lib/libmd.so.5 (0x109000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /lib/libcrypt.so.5 (0x121000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /lib/libkvm.so.5 (0x147000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /lib/libutil.so.9 (0x159000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/lib/libssl.so.6 (0x16a000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/local/lib/libxml2.so.5 (0x1b3000)
--60907-- Reading syms from /lib/libz.so.6 (0x2dd000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /usr/local/lib/libiconv.so.3 (0x2f1000)
--60907-- Reading syms from /lib/libm.so.5 (0x3ea000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /lib/libthr.so.3 (0x404000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /lib/libc.so.7 (0x425000)
--60907--    object doesn't have a symbol table
--60907-- Reading syms from /lib/libcrypto.so.6 (0x544000)
--60907--    object doesn't have a symbol table
--60907-- REDIR: 0x51739c (memcpy) redirected to 0x5e850 (memcpy)
--60907-- REDIR: 0x511af0 (strlen) redirected to 0x5cf40 (strlen)
--60907-- REDIR: 0x511128 (strncmp) redirected to 0x5cfa0 (strncmp)
--60907-- REDIR: 0x498ae0 (malloc) redirected to 0x5bf30 (malloc)
--60907-- REDIR: 0x51735c (memset) redirected to 0x5d390 (memset)
--60907-- REDIR: 0x4989a0 (calloc) redirected to 0x5b010 (calloc)
--60907-- REDIR: 0x4b75a4 (strrchr) redirected to 0x5ccb0 (strrchr)
--60907-- REDIR: 0x5111c0 (strcpy) redirected to 0x5f150 (strcpy)
--60907-- REDIR: 0x511220 (strchr) redirected to 0x5cd70 (strchr)
--60907-- REDIR: 0x4fd11c (strcmp) redirected to 0x5d0f0 (strcmp)
--60907-- REDIR: 0x4fd190 (strcat) redirected to 0x5dce0 (strcat)
--60907-- REDIR: 0x498c10 (free) redirected to 0x5bad0 (free)
--60907-- REDIR: 0x50f5a0 (setenv) redirected to 0x5d7d0 (setenv)
--60907-- REDIR: 0x4992e0 (realloc) redirected to 0x5bff0 (realloc)
--60907-- REDIR: 0x5152d8 (memchr) redirected to 0x5d210 (memchr)
Command Shell daemon configuration parameters:
  sock_file    = /usr/local/fnp/web/tmp/fnp_shd.sock
  pid_file     = /usr/local/fnp/var/fnp_shd.pid
  syslog_ident = fnp
  lang         = ru
  is_daemon    = yes
  is_debug     = yes
  dlevel       = 63
--60907-- REDIR: 0x50e850 (strnlen) redirected to 0x5cf10 (strnlen)
--60907-- REDIR: 0x4fc390 (strncpy) redirected to 0x5ee90 (strncpy)
--60907-- REDIR: 0x513148 (memmove) redirected to 0x5d510 (memmove)
--60907-- sigprocmask: unknown 'how' field 0
--60907-- REDIR: 0x511b80 (stpcpy) redirected to 0x5e180 (stpcpy)
--60907-- REDIR: 0x4f3d80 (strcasecmp) redirected to 0x5dc70 (strcasecmp)
==60907== 
==60907== HEAP SUMMARY:
==60907==     in use at exit: 27,939 bytes in 277 blocks
==60907==   total heap usage: 25,729 allocs, 25,452 frees, 1,121,521 bytes allocated
==60907== 
==60907== Searching for pointers to 277 not-freed blocks
==60907== Checked 810,992 bytes
==60907== 
==60907== LEAK SUMMARY:
==60907==    definitely lost: 0 bytes in 0 blocks
==60907==    indirectly lost: 0 bytes in 0 blocks
==60907==      possibly lost: 0 bytes in 0 blocks
==60907==    still reachable: 27,939 bytes in 277 blocks
==60907==         suppressed: 0 bytes in 0 blocks
==60907== Reachable blocks (those to which a pointer was found) are not shown.
==60907== To see them, rerun with: --leak-check=full --show-reachable=yes
==60907== 
==60907== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==60907== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

версия - valgrind-3.6.1, система - FreeBSD 9.0-RELEASE, i386

Это не нормально, как и Ваша 1я проблема. Вероятно ошибки/вольности в обработчике SIGTERM или в коде завершения демона

Допускаю, вот и хочу разобраться. Ведь при обычном запуске завершался нормально, адекватно обрабатывал SIGTERM, комментил все в логах. А под Valgrind-ом даже в логах по поводу обработки данного сигнала нет ничего, и сообщений об ощибках тоже в логах нет. Сам valgrind же выдает SIGSEGV, и показывает стек вызовов неразборчиво, хотя я компилировала демон специально без оптимизации и с отладочной инфой, стек указывает куда-то вглубь вызова select(), отладчик по дампу, который сгенерировал Valgrind, тоже мало показал. Вот так выглядит стек в Valgrind :

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Thread 2:
==15271== Invalid read of size 4
==15271==    at 0x3F7F24: ??? (in /lib/libthr.so.3)
==15271==    by 0x3F8164: ??? (in /lib/libthr.so.3)
==15271==    by 0x3803DFCF: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd)
==15271==    by 0x8052229: shd_freepthr_func (shd_pthread.c:1109)
==15271==    by 0x3F34B9: ??? (in /lib/libthr.so.3)
==15271==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==15271== 
==15271== 
==15271== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==15271==  Access not within mapped region at address 0x0
==15271==    at 0x3F7F24: ??? (in /lib/libthr.so.3)
==15271==    by 0x3F8164: ??? (in /lib/libthr.so.3)
==15271==    by 0x3803DFCF: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd)
==15271==    by 0x8052229: shd_freepthr_func (shd_pthread.c:1109)
==15271==    by 0x3F34B9: ??? (in /lib/libthr.so.3)
==15271==  If you believe this happened as a result of a stack
==15271==  overflow in your program's main thread (unlikely but
==15271==  possible), you can try to increase the size of the
==15271==  main thread stack using the --main-stacksize= flag.
==15271==  The main thread stack size used in this run was 16777216.

(на данной строчке кода как раз select())

это стек вызовов при разборе дампа отладчиком :

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0040ef24 in pthread_sigmask () from /lib/libthr.so.3
[New Thread 9a0670 (LWP 100101/<unknown>)]
[New Thread 6b6030 (LWP 100058/<unknown>)]
(gdb) thread apply all bt
 
Thread 2 (Thread 6b6030 (LWP 100058/<unknown>)):
#0  0x00516c83 in select () from /lib/libc.so.7
#1  0x0040ce30 in select () from /lib/libthr.so.3
#2  0x0804b3e1 in main (argc=3, argv=0xbebfec74) at fnp_shd.c:456
 
Thread 1 (Thread 9a0670 (LWP 100101/<unknown>)):
#0  0x0040ef24 in pthread_sigmask () from /lib/libthr.so.3
#1  0x0040f165 in pthread_sigmask () from /lib/libthr.so.3
#2  0x3803dfd0 in ?? ()
#3  0x0000000f in ?? ()
#4  0xbf9fe840 in ?? ()
#5  0x00000000 in ?? ()
#6  0x00000000 in ?? ()
#7  0x00000000 in ?? ()
#8  0x00000000 in ?? ()
#9  0x00000000 in ?? ()
#10 0x00080000 in rp_vlan_brief (str=0x7 <Address 0x7 out of bounds>, vg=0xbf9fef00, pvt=0x0, mode=0, 
    where=-1080037504, cfg=0x9a0670) at libparse.c:653
#11 0x08054107 in shd_freepthr_func (arg=0x9a0530) at shd_pthread.c:1109
#12 0x0040a4ba in pthread_getprio () from /lib/libthr.so.3
#13 0x00000000 in ?? ()
#14 0x009a0670 in ?? ()
Cannot access memory at address 0xbf9ff000

Есть ли еще какие-то опции, которые смогут природу ошибки прояснить? По документации я разумеется, роюсь, спасибо за ссылку, просто сразу все не охватить, и пока той информации, что мне необходима, не нахожу.

g_u_e_s_t · 27.06.2012, 11:58

Сообщение от margosh

система - FreeBSD 9.0-RELEASE, i386

Этого было бы достаточно

У фри SIG_BLOCK всегда и везде 1 в отличии от линуксового бардака. Название раздела, как бы намикает, что не плохо бы указывать ОС в случае отличая от дефолтной

Сообщение от margosh

Есть ли еще какие-то опции, которые смогут природу ошибки прояснить?

Если падает как Вы говорите в select()е и с fd_set'ами 100% все хорошо (а вдруг действительно весь стек скушали), то идей вообще-то нет... т.е. как обычно: выпиливаем минимальный кусок кода на котором можно воспроизвести, думаем, чиним или жалуемся.
У меня нет опыта работы с valgrind на freebsd. Если не хотите/не можете отлаживать на линуксе, то могу только посоветовать обновиться на последнюю версию (лучше взять из git) фришного форка (кстати если правильно помню, там русскоязычный мантейнер, можно пробовать написать ему).

Например с ходу нагуглилось про фришную версию:

Fix incorrect handling of fork() in the parent process. Valgrind
was using an incorrect check to see if we were the parent, meaning
that valgrind would never call do_atfork_parent() as required,
which could cause a crash later on if the parent had to grow its
stack.

Courtesy of Ryan Berryhill (rberryhill AT sandvine DOT com)

Who
Ryan Stone
When
24 May 2012

@margosh · 27.06.2012, 12:23 **[ТС]**

Этого было бы достаточно У фри SIG_BLOCK всегда и везде 1 в отличии от линуксового бардака. Название раздела, как бы намикает, что не плохо бы указывать ОС в случае отличая от дефолтной

учту на будущее, хотчя считаю этот раздел ближайшим по смыслу к данной теме, т.к раздела "С под Unix" не нашлось, и на возможность влияния на данный вопрос ОС уже указывала ранее как раз по причине "не Линукса"

Если падает как Вы говорите в select()е и с fd_set'ами 100% все хорошо (а вдруг действительно весь стек скушали)

плохо представляю, что может с fd_set'ами случиться такого критичного, а насчет стека - рекурсий никаких нет, куда он скушаться мог? Разве если только Valgrind, опять же, делает с ним что-то о чем я пока не знаю... Попробую обновиться до другой версии.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Основы отладки веб-приложений на SDL3 по USB и Wi-Fi, запущенных в браузере мобильных устройств 8Observer8 07.02.2026 Содержание блога Браузер Chrome имеет средства для отладки мобильных веб-приложений по USB. В этой пошаговой инструкции ограничимся работой с консолью. Вывод в консоль - это часть процесса. . .	SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .
SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .

@margosh 0 / 0 / 0 Регистрация: 15.05.2012 Сообщений: 8

	Может ли Valgrind влиять на выполнение программы? 20.06.2012, 17:06. Показов 2458. Ответов 8 Метки нет (Все метки) Всем добрый день! Столкнулась со следующим : при запуске программы под Valgrind(Memcheck) функция sigpromask() завершается с ошибкой, в то время как при обычном запуске - работает нормально. Каким образом Valgrind может влиять на работу данной функции, и как исправить это досадное недоразумение? 0

@margosh 0 / 0 / 0 Регистрация: 15.05.2012 Сообщений: 8
	25.06.2012, 14:56 [ТС]
	@g_u_e_s_t, спасибо, Вы навели меня на мысль, в какую сторону копать. Более-менее разобралась : Valgrind-у не давал покоя как раз параметр "how" - несмотря на то, что это чтение маски, а не запись, он анализировался. Я по примеру из книжки передала в качестве этого параметра 0, без Valgrind работало нормально, с ним - нет. Я бы не прочь узнать природу ошибки, однако Valgrind завершал работу еще до печати сообщения из обработчика ошибки, и сам номер не выводил. Возможно, требуются какие-то допопции... Вобщем, я поменяла аргумент "how" с 0 на SIG_UNBLOCK, и программа продолжила выполнение под Valgrind, как и предполагалось. 0