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.