Bug 259776

Summary:	(my) Application doesn't trap signals if compiled in gcc with debugger symbols
Product:	[Developer tools] valgrind	Reporter:	icegood <icegood1980>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED WAITINGFORINFO
Severity:	normal	CC:	borntraeger, pjfloyd
Priority:	NOR
Version First Reported In:	3.5.0
Target Milestone:	---
Platform:	Unlisted Binaries
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description icegood 2010-12-13 21:59:38 UTC

Platform hasn't chosen because on both systems doesnt work:
1) uname -a
Linux *** 2.6.35-020635-generic #020635 SMP Mon Aug 2 10:16:00 UTC 2010 i686 GNU/Linux
with Debian lenny and
valgrind-3.3.1-Debian on it
2) uname -a
Linux *** 2.6.18-194.17.1.el5 #1 SMP Wed Sep 29 12:09:22 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
based on Scientific Linux 5
and
valgrind-3.5.0 inside


So, when program compiled without debug symbols (gcc -O3) - everything is OK, after sending SIGINT ctrl-C program traps it and finishes good being under valgrind. 
Once compiled with debug symbols in gcc then sending signal to it just kills program without any trapping, so i cannot debug it behavior being under valgrind.

Comment 1 Christian Borntraeger 2010-12-14 10:24:49 UTC

Sometimes it takes a while for valgrind to parse all debug data if the program is very big. Can you run with -d -v and check if the program is really started or if valgrind is still parsing the debug data.

If that is not the problem, can you post

- the test program
- the full compile options for _both_ cases
- the compiler versions?

Comment 2 icegood 2010-12-14 15:22:05 UTC

(In reply to comment #1)
> If that is not the problem
It's defenetly not problem because within initialization program writes to stdout/stderr init info and i see it

> - the test program
> - the full compile options for _both_ cases
> - the compiler versions?
OK, i will do that later

Comment 3 Paul Floyd 2022-12-24 14:15:45 UTC

Don't think we will ever get info to reproduce this.