valgrind-users

[Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[ppmoore <pol...@gm...>]

Hello,

I've been trying to use valgrind v3.6.0 to debug a cross-compiled Power-PC
application.
I believe I built valgrind correctly, using the two-stage build procedure:
./valgrind --version
valgrind-3.6.0

The problem I have is that valgrind prematurely exits after about 10
seconds: 
==624== Process terminating with default action of signal 14 (SIGALRM)
==624==    at 0xF9D5BA4: socket (in /lib/libc-2.3.2.so)

I checked using ps that the application was not yet started when valgrind
terminated.

I used the command:
./valgrind -v --tool=memcheck --leak-check=yes <application>

I have attached the full transcript output:
http://old.nabble.com/file/p30891730/valgrind.log valgrind.log 

Can anyone help?

Many thanks,
Paul


-- 
View this message in context: http://old.nabble.com/Process-terminating-with-default-action-of-signal-14-%28SIGALRM%29-tp30891730p30891730.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[Tom H. <to...@co...>]

On 10/02/11 13:21, ppmoore wrote:

> The problem I have is that valgrind prematurely exits after about 10
> seconds: 
> ==624== Process terminating with default action of signal 14 (SIGALRM)
> ==624==    at 0xF9D5BA4: socket (in /lib/libc-2.3.2.so)

Termination is the default behaviour for SIGALRM so that is the expected
behaviour if a SIGALRM is received.

If I had to guess I would say you program is arranging for an alarm
signal (probably with the alarm() function) before it has made
arrangements to handle the resulting signal and, when running under
valgrind, the alarm expires before it gets around to installing the
signal handler.

> I checked using ps that the application was not yet started when valgrind
> terminated.

How did you check that? The valgrind process *is* the application.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[ppmoore <pol...@gm...>]

Hello Tom, thanks for the quick reply.

The signal SIGALRM is handled in the main constructor for the application,
invoked from main(), so I thought that this should be sufficiently quick.

	if (signal(SIGALRM, &signalHandler) == SIG_ERR)
	{
		log_printf(LOG_ERR, "Signal when registering SIGALRM handler\n");
		return -1;
	}

IS there a way top change the default signal-handling in valgrind?

Sorry, about using PS to check for the running application, I was expecting
gdb-link behaviour, where the application being debugged could be observed
in the running process list.

Paul



Bugzilla from to...@co... wrote:
> 
> On 10/02/11 13:21, ppmoore wrote:
> 
>> The problem I have is that valgrind prematurely exits after about 10
>> seconds: 
>> ==624== Process terminating with default action of signal 14 (SIGALRM)
>> ==624==    at 0xF9D5BA4: socket (in /lib/libc-2.3.2.so)
> 
> Termination is the default behaviour for SIGALRM so that is the expected
> behaviour if a SIGALRM is received.
> 
> If I had to guess I would say you program is arranging for an alarm
> signal (probably with the alarm() function) before it has made
> arrangements to handle the resulting signal and, when running under
> valgrind, the alarm expires before it gets around to installing the
> signal handler.
> 
>> I checked using ps that the application was not yet started when valgrind
>> terminated.
> 
> How did you check that? The valgrind process *is* the application.
> 
> Tom
> 
> -- 
> Tom Hughes (to...@co...)
> http://compton.nu/
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 

-- 
View this message in context: http://old.nabble.com/Process-terminating-with-default-action-of-signal-14-%28SIGALRM%29-tp30891730p30892671.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[Tom H. <to...@co...>]

On 10/02/11 14:10, ppmoore wrote:

> The signal SIGALRM is handled in the main constructor for the application,
> invoked from main(), so I thought that this should be sufficiently quick.
> 
> 	if (signal(SIGALRM, &signalHandler) == SIG_ERR)
> 	{
> 		log_printf(LOG_ERR, "Signal when registering SIGALRM handler\n");
> 		return -1;
> 	}

The important question is not just where that is, but where the code
that arranges for the SIGALRM to be sent is relative to that. It should
be after that code not before it basically.

> IS there a way top change the default signal-handling in valgrind?

No, any more than there is any way to change the kernel's signal
handling when you are running outside valgrind.

Valgrind is only doing exactly what the kernel would normally do - the
only difference is that your program is probably running more slowly
because it is running under valgrind.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[WAROQUIERS P. <phi...@eu...>]

Who is sending this SIGALRM  to the process ?
If this is another process (e.g. a "supervision" process),
then as your process starts under valgrind a lot
slower, the "timer" used by the supervision process might need to be
made bigger.

Philippe

>-----Original Message-----
>From: ppmoore [mailto:pol...@gm...] 
>Sent: Thursday 10 February 2011 15:36
>To: val...@li...
>Subject: Re: [Valgrind-users] Process terminating with default 
>action of signal 14 (SIGALRM)
>
>
>Tom,
>
>I inserted a logging statement in the constructor invoked 
>immediately after
>startup, and I noticed that it wasn't logged. I don't believe that the
>program was even invoked before valgrind decided to exit.
>
>I hope I'm wrong, but can it be that valgrind can't handle our 
>application
>in this cross-compiled environment? In theory it shouldn't matter...
>
>Thanks for the help,
>Paul
>
>
>
>
>Tom Hughes-2 wrote:
>> 
>> On 10/02/11 14:10, ppmoore wrote:
>> 
>>> The signal SIGALRM is handled in the main constructor for the
>>> application,
>>> invoked from main(), so I thought that this should be 
>sufficiently quick.
>>> 
>>> 	if (signal(SIGALRM, &signalHandler) == SIG_ERR)
>>> 	{
>>> 		log_printf(LOG_ERR, "Signal when registering 
>SIGALRM handler\n");
>>> 		return -1;
>>> 	}
>> 
>> The important question is not just where that is, but where the code
>> that arranges for the SIGALRM to be sent is relative to 
>that. It should
>> be after that code not before it basically.
>> 
>>> IS there a way top change the default signal-handling in valgrind?
>> 
>> No, any more than there is any way to change the kernel's signal
>> handling when you are running outside valgrind.
>> 
>> Valgrind is only doing exactly what the kernel would 
>normally do - the
>> only difference is that your program is probably running more slowly
>> because it is running under valgrind.
>> 
>> Tom
>> 
>> -- 
>> Tom Hughes (to...@co...)
>> http://compton.nu/
>> 
>> 
>---------------------------------------------------------------
>---------------
>> The ultimate all-in-one performance toolkit: Intel(R) 
>Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit 
>performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>> 
>> 
>
>-- 
>View this message in context: 
>http://old.nabble.com/Process-terminating-with-default-action-o
f-signal-14-%28SIGALRM%29-tp30891730p30892908.html
>Sent from the Valgrind - Users mailing list archive at Nabble.com.
>
>
>---------------------------------------------------------------
>---------------
>The ultimate all-in-one performance toolkit: Intel(R) Parallel 
>Studio XE:
>Pinpoint memory and threading errors before they happen.
>Find and fix more than 250 security defects in the development cycle.
>Locate bottlenecks in serial and parallel code that limit performance.
>http://p.sf.net/sfu/intel-dev2devfeb
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

____
 
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
 
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
 
Any views expressed in this message are those of the sender.

Re: [Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[ppmoore <pol...@gm...>]

Tom, Philippe,

Thanks for the input. 

Before I go further, I need to investigate the various error message I get
when valgrind starts up.
I've covered this under a separate post in this forum.

Paul
-- 
View this message in context: http://old.nabble.com/Process-terminating-with-default-action-of-signal-14-%28SIGALRM%29-tp30891730p30902022.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Process terminating with default action of signal 14 (SIGALRM)

[ppmoore <pol...@gm...>]

Tom,

I inserted a logging statement in the constructor invoked immediately after
startup, and I noticed that it wasn't logged. I don't believe that the
program was even invoked before valgrind decided to exit.

I hope I'm wrong, but can it be that valgrind can't handle our application
in this cross-compiled environment? In theory it shouldn't matter...

Thanks for the help,
Paul




Tom Hughes-2 wrote:
> 
> On 10/02/11 14:10, ppmoore wrote:
> 
>> The signal SIGALRM is handled in the main constructor for the
>> application,
>> invoked from main(), so I thought that this should be sufficiently quick.
>> 
>> 	if (signal(SIGALRM, &signalHandler) == SIG_ERR)
>> 	{
>> 		log_printf(LOG_ERR, "Signal when registering SIGALRM handler\n");
>> 		return -1;
>> 	}
> 
> The important question is not just where that is, but where the code
> that arranges for the SIGALRM to be sent is relative to that. It should
> be after that code not before it basically.
> 
>> IS there a way top change the default signal-handling in valgrind?
> 
> No, any more than there is any way to change the kernel's signal
> handling when you are running outside valgrind.
> 
> Valgrind is only doing exactly what the kernel would normally do - the
> only difference is that your program is probably running more slowly
> because it is running under valgrind.
> 
> Tom
> 
> -- 
> Tom Hughes (to...@co...)
> http://compton.nu/
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 

-- 
View this message in context: http://old.nabble.com/Process-terminating-with-default-action-of-signal-14-%28SIGALRM%29-tp30891730p30892908.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.