[PATCH] Increase timeout on gdb.base/exitsignal.exp

[PATCH] Increase timeout on gdb.base/exitsignal.exp

[Sergio Durigan Junior]

I have noticed that BuildBot is showing random failures of
gdb.base/exitsignal.exp, specifically when testing on the
Fedora-ppc64be-native-gdbserver-m64 builder.  Since I wrote this test
a while ago, I decided to investigate this further.

This is what you see when you examine gdb.log:

  Breakpoint 1, main (argc=1, argv=0x3fffffffe3c8) at ../../../binutils-gdb/gdb/testsuite/gdb.base/segv.c:26
  26	     raise (SIGSEGV);
  (gdb) print $_exitsignal
  $1 = void
  (gdb) PASS: gdb.base/exitsignal.exp: $_exitsignal is void before running
  print $_exitcode
  $2 = void
  (gdb) PASS: gdb.base/exitsignal.exp: $_exitcode is void before running
  continue
  Continuing.

  Program received signal SIGSEGV, Segmentation fault.
  0x00003fffb7cbf808 in .raise () from target:/lib64/libc.so.6
  (gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
  continue
  Continuing.
  FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV (timeout)
  print $_exitsignal
  FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after SIGSEGV. (timeout)
  print $_exitcode
  FAIL: gdb.base/exitsignal.exp: $_exitcode is still void after SIGSEGV (timeout)
  kill

  Program terminated with signal SIGSEGV, Segmentation fault.
  The program no longer exists.
  (gdb) print $_exitsignal
  $3 = 11
  (gdb) print $_exitcode
  $4 = void

Clearly a timeout issue: one can see that even though the tests failed
because the program was still running, both 'print' commands actually
succeeded later.

I could not reproduce this timeout here, but I decided to propose this
timeout increase anyway.  I have chosen to increase it by a factor of
10; that should give GDB/gdbserver plenty of time to reach the SEGV
point.

For clarity, I am also attaching the output of 'git diff -w' here; it
makes things much easier to visualize.

OK to apply?

diff --git a/gdb/testsuite/gdb.base/exitsignal.exp b/gdb/testsuite/gdb.base/exitsignal.exp
index ae0adf4a9b..fdb3b13 100644
### a/gdb/testsuite/gdb.base/exitsignal.exp
### b/gdb/testsuite/gdb.base/exitsignal.exp
@@ -37,6 +37,7 @@ if { ![runto_main] } {
     return -1
 }
 
+with_timeout_factor 10 {
     # Print $_exitsignal.  It should be void now, because nothing
     # happened.
     gdb_test "print \$_exitsignal" " = void" \
@@ -45,6 +46,7 @@ gdb_test "print \$_exitsignal" " = void" \
     # Just to guarantee, making sure that $_exitcode is also void.
     gdb_test "print \$_exitcode" " = void" \
 	"\$_exitcode is void before running"
+}
 
 # Trigger SIGSEGV.
 gdb_test "continue" "Program received signal SIGSEGV.*" "trigger SIGSEGV"
@@ -53,6 +55,7 @@ gdb_test "continue" "Program received signal SIGSEGV.*" "trigger SIGSEGV"
 gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
     "program terminated with SIGSEGV"
 
+with_timeout_factor 10 {
     # Now, print $_exitsignal again.  It should be 11 (SIGSEGV).
     gdb_test "print \$_exitsignal" " = 11" \
 	"\$_exitsignal is 11 (SIGSEGV) after SIGSEGV."
@@ -61,10 +64,12 @@ gdb_test "print \$_exitsignal" " = 11" \
     # of a signal, and did not return.
     gdb_test "print \$_exitcode" " = void" \
 	"\$_exitcode is still void after SIGSEGV"
+}
 
 # Re-run to main, i.e., restart the executable.
 rerun_to_main
 
+with_timeout_factor 10 {
     # Print the $_exitsignal again.  Even in this normal scenario, it
     # should still contain the signal triggered in the other run.
     gdb_test "print \$_exitsignal" " = 11" \
@@ -73,6 +78,7 @@ gdb_test "print \$_exitsignal" " = 11" \
     # And, again, print $_exitcode.
     gdb_test "print \$_exitcode" " = void" \
 	"\$_exitcode is still void after restarting the inferior"
+}
 
 # Now we test the behaviour of $_exit{code,signal} during a normal
 # inferior execution.
@@ -82,12 +88,14 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
     return -1
 }
 
+with_timeout_factor 10 {
     # Checking $_exitsignal and $_exitcode, both should be void before the
     # inferior is executed.
     gdb_test "print \$_exitsignal" " = void" \
 	"\$_exitsignal is void before normal inferior is executed"
     gdb_test "print \$_exitcode" " = void" \
 	"\$_exitcode is void before normal inferior is executed"
+}
 
 # Run the inferior until the end.
 if { ![runto_main] } {
@@ -96,6 +104,7 @@ if { ![runto_main] } {
 
 gdb_continue_to_end
 
+with_timeout_factor 10 {
     # Checking $_exitcode.  It should be 0.
     gdb_test "print \$_exitcode" " = 0" \
 	"\$_exitcode is zero after normal inferior is executed"
@@ -104,3 +113,4 @@ gdb_test "print \$_exitcode" " = 0" \
     # has not received any signal.
     gdb_test "print \$_exitsignal" " = void" \
 	"\$_exitsignal is still void after normal inferior is executed"
+}


gdb/testsuite/ChangeLog:
2015-08-25  Sergio Durigan Junior  <sergiodj@redhat.com>

	* gdb.base/exitsignal.exp: Increase timeout of 'print' commands by
	a factor of 10.
---
 gdb/testsuite/gdb.base/exitsignal.exp | 80 ++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 35 deletions(-)

diff --git a/gdb/testsuite/gdb.base/exitsignal.exp b/gdb/testsuite/gdb.base/exitsignal.exp
index ae0adf4a9b..fdb3b13 100644
--- a/gdb/testsuite/gdb.base/exitsignal.exp
+++ b/gdb/testsuite/gdb.base/exitsignal.exp
@@ -37,14 +37,16 @@ if { ![runto_main] } {
     return -1
 }
 
-# Print $_exitsignal.  It should be void now, because nothing
-# happened.
-gdb_test "print \$_exitsignal" " = void" \
-    "\$_exitsignal is void before running"
-
-# Just to guarantee, making sure that $_exitcode is also void.
-gdb_test "print \$_exitcode" " = void" \
-    "\$_exitcode is void before running"
+with_timeout_factor 10 {
+    # Print $_exitsignal.  It should be void now, because nothing
+    # happened.
+    gdb_test "print \$_exitsignal" " = void" \
+	"\$_exitsignal is void before running"
+
+    # Just to guarantee, making sure that $_exitcode is also void.
+    gdb_test "print \$_exitcode" " = void" \
+	"\$_exitcode is void before running"
+}
 
 # Trigger SIGSEGV.
 gdb_test "continue" "Program received signal SIGSEGV.*" "trigger SIGSEGV"
@@ -53,26 +55,30 @@ gdb_test "continue" "Program received signal SIGSEGV.*" "trigger SIGSEGV"
 gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
     "program terminated with SIGSEGV"
 
-# Now, print $_exitsignal again.  It should be 11 (SIGSEGV).
-gdb_test "print \$_exitsignal" " = 11" \
-    "\$_exitsignal is 11 (SIGSEGV) after SIGSEGV."
+with_timeout_factor 10 {
+    # Now, print $_exitsignal again.  It should be 11 (SIGSEGV).
+    gdb_test "print \$_exitsignal" " = 11" \
+	"\$_exitsignal is 11 (SIGSEGV) after SIGSEGV."
 
-# And $_exitcode should still be void, since the inferior died because
-# of a signal, and did not return.
-gdb_test "print \$_exitcode" " = void" \
-    "\$_exitcode is still void after SIGSEGV"
+    # And $_exitcode should still be void, since the inferior died because
+    # of a signal, and did not return.
+    gdb_test "print \$_exitcode" " = void" \
+	"\$_exitcode is still void after SIGSEGV"
+}
 
 # Re-run to main, i.e., restart the executable.
 rerun_to_main
 
-# Print the $_exitsignal again.  Even in this normal scenario, it
-# should still contain the signal triggered in the other run.
-gdb_test "print \$_exitsignal" " = 11" \
-    "\$_exitsignal is 11 (SIGSEGV) after restarting the inferior"
+with_timeout_factor 10 {
+    # Print the $_exitsignal again.  Even in this normal scenario, it
+    # should still contain the signal triggered in the other run.
+    gdb_test "print \$_exitsignal" " = 11" \
+	"\$_exitsignal is 11 (SIGSEGV) after restarting the inferior"
 
-# And, again, print $_exitcode.
-gdb_test "print \$_exitcode" " = void" \
-    "\$_exitcode is still void after restarting the inferior"
+    # And, again, print $_exitcode.
+    gdb_test "print \$_exitcode" " = void" \
+	"\$_exitcode is still void after restarting the inferior"
+}
 
 # Now we test the behaviour of $_exit{code,signal} during a normal
 # inferior execution.
@@ -82,12 +88,14 @@ if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
     return -1
 }
 
-# Checking $_exitsignal and $_exitcode, both should be void before the
-# inferior is executed.
-gdb_test "print \$_exitsignal" " = void" \
-    "\$_exitsignal is void before normal inferior is executed"
-gdb_test "print \$_exitcode" " = void" \
-    "\$_exitcode is void before normal inferior is executed"
+with_timeout_factor 10 {
+    # Checking $_exitsignal and $_exitcode, both should be void before the
+    # inferior is executed.
+    gdb_test "print \$_exitsignal" " = void" \
+	"\$_exitsignal is void before normal inferior is executed"
+    gdb_test "print \$_exitcode" " = void" \
+	"\$_exitcode is void before normal inferior is executed"
+}
 
 # Run the inferior until the end.
 if { ![runto_main] } {
@@ -96,11 +104,13 @@ if { ![runto_main] } {
 
 gdb_continue_to_end
 
-# Checking $_exitcode.  It should be 0.
-gdb_test "print \$_exitcode" " = 0" \
-    "\$_exitcode is zero after normal inferior is executed"
+with_timeout_factor 10 {
+    # Checking $_exitcode.  It should be 0.
+    gdb_test "print \$_exitcode" " = 0" \
+	"\$_exitcode is zero after normal inferior is executed"
 
-# Checking $_exitsignal.  It should still be void, since the inferior
-# has not received any signal.
-gdb_test "print \$_exitsignal" " = void" \
-    "\$_exitsignal is still void after normal inferior is executed"
+    # Checking $_exitsignal.  It should still be void, since the inferior
+    # has not received any signal.
+    gdb_test "print \$_exitsignal" " = void" \
+	"\$_exitsignal is still void after normal inferior is executed"
+}
-- 
2.4.3

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Pedro Alves]

On 08/25/2015 06:42 AM, Sergio Durigan Junior wrote:
> I have noticed that BuildBot is showing random failures of
> gdb.base/exitsignal.exp, specifically when testing on the
> Fedora-ppc64be-native-gdbserver-m64 builder.  Since I wrote this test
> a while ago, I decided to investigate this further.
> 
> This is what you see when you examine gdb.log:
> 
>   Breakpoint 1, main (argc=1, argv=0x3fffffffe3c8) at ../../../binutils-gdb/gdb/testsuite/gdb.base/segv.c:26
>   26	     raise (SIGSEGV);
>   (gdb) print $_exitsignal
>   $1 = void
>   (gdb) PASS: gdb.base/exitsignal.exp: $_exitsignal is void before running
>   print $_exitcode
>   $2 = void
>   (gdb) PASS: gdb.base/exitsignal.exp: $_exitcode is void before running
>   continue
>   Continuing.
> 
>   Program received signal SIGSEGV, Segmentation fault.
>   0x00003fffb7cbf808 in .raise () from target:/lib64/libc.so.6
>   (gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
>   continue
>   Continuing.
>   FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV (timeout)
>   print $_exitsignal
>   FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after SIGSEGV. (timeout)
>   print $_exitcode
>   FAIL: gdb.base/exitsignal.exp: $_exitcode is still void after SIGSEGV (timeout)
>   kill
> 
>   Program terminated with signal SIGSEGV, Segmentation fault.
>   The program no longer exists.
>   (gdb) print $_exitsignal
>   $3 = 11
>   (gdb) print $_exitcode
>   $4 = void
> 
> Clearly a timeout issue: one can see that even though the tests failed
> because the program was still running, both 'print' commands actually
> succeeded later.
>

I recently bumped time outs for a few reverse/record tests, but in that
case, it's justified because recording requires single-stepping all
instructions, so it naturally takes a while.  In this case, I don't see what
could reasonably be causing the delay.  It shouldn't really ever take 60
seconds just to deliver a signal and have the kernel report back
process exit.  What could cause this delay?  I'm not sure whether the
process's signalled exit status is reported to the parent before or after
the kernel fully writes the core dump --- it occurred to me that if after,
then writing a big core dump could explain a delay.  So I would
suggest switching to a signal that does cause a core dump by default,
like e.g., SIGKILL/SIGTERM.  Though in this case, the core dump generated
should be small, so I'm mystified.  This could be papering over some
latent problem...

> I could not reproduce this timeout here, but I decided to propose this
> timeout increase anyway.  I have chosen to increase it by a factor of
> 10; that should give GDB/gdbserver plenty of time to reach the SEGV
> point.
> 
> For clarity, I am also attaching the output of 'git diff -w' here; it
> makes things much easier to visualize.
> 
> OK to apply?


>  gdb_continue_to_end
>  
> -# Checking $_exitcode.  It should be 0.
> -gdb_test "print \$_exitcode" " = 0" \
> -    "\$_exitcode is zero after normal inferior is executed"
> +with_timeout_factor 10 {
> +    # Checking $_exitcode.  It should be 0.
> +    gdb_test "print \$_exitcode" " = 0" \
> +	"\$_exitcode is zero after normal inferior is executed"
>  
> -# Checking $_exitsignal.  It should still be void, since the inferior
> -# has not received any signal.
> -gdb_test "print \$_exitsignal" " = void" \
> -    "\$_exitsignal is still void after normal inferior is executed"
> +    # Checking $_exitsignal.  It should still be void, since the inferior
> +    # has not received any signal.
> +    gdb_test "print \$_exitsignal" " = void" \
> +	"\$_exitsignal is still void after normal inferior is executed"
> +}
> 

This (many instances) doesn't make sense to me.  And I think wouldn't
fix anything.  Seems to me the bumped timeout, if any, should be around
the continue that caused the first time out:

# Continue until the end.
gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
    "program terminated with SIGSEGV"

Thanks,
Pedro Alves

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Sergio Durigan Junior]

On Tuesday, August 25 2015, Pedro Alves wrote:

> On 08/25/2015 06:42 AM, Sergio Durigan Junior wrote:
>> I have noticed that BuildBot is showing random failures of
>> gdb.base/exitsignal.exp, specifically when testing on the
>> Fedora-ppc64be-native-gdbserver-m64 builder.  Since I wrote this test
>> a while ago, I decided to investigate this further.
>> 
>> This is what you see when you examine gdb.log:
>> 
>>   Breakpoint 1, main (argc=1, argv=0x3fffffffe3c8) at ../../../binutils-gdb/gdb/testsuite/gdb.base/segv.c:26
>>   26	     raise (SIGSEGV);
>>   (gdb) print $_exitsignal
>>   $1 = void
>>   (gdb) PASS: gdb.base/exitsignal.exp: $_exitsignal is void before running
>>   print $_exitcode
>>   $2 = void
>>   (gdb) PASS: gdb.base/exitsignal.exp: $_exitcode is void before running
>>   continue
>>   Continuing.
>> 
>>   Program received signal SIGSEGV, Segmentation fault.
>>   0x00003fffb7cbf808 in .raise () from target:/lib64/libc.so.6
>>   (gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
>>   continue
>>   Continuing.
>>   FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV (timeout)
>>   print $_exitsignal
>>   FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after SIGSEGV. (timeout)
>>   print $_exitcode
>>   FAIL: gdb.base/exitsignal.exp: $_exitcode is still void after SIGSEGV (timeout)
>>   kill
>> 
>>   Program terminated with signal SIGSEGV, Segmentation fault.
>>   The program no longer exists.
>>   (gdb) print $_exitsignal
>>   $3 = 11
>>   (gdb) print $_exitcode
>>   $4 = void
>> 
>> Clearly a timeout issue: one can see that even though the tests failed
>> because the program was still running, both 'print' commands actually
>> succeeded later.
>>
>
> I recently bumped time outs for a few reverse/record tests, but in that
> case, it's justified because recording requires single-stepping all
> instructions, so it naturally takes a while.  In this case, I don't see what
> could reasonably be causing the delay.  It shouldn't really ever take 60
> seconds just to deliver a signal and have the kernel report back
> process exit.  What could cause this delay?  I'm not sure whether the
> process's signalled exit status is reported to the parent before or after
> the kernel fully writes the core dump --- it occurred to me that if after,
> then writing a big core dump could explain a delay.  So I would
> suggest switching to a signal that does cause a core dump by default,
> like e.g., SIGKILL/SIGTERM.  Though in this case, the core dump generated
> should be small, so I'm mystified.  This could be papering over some
> latent problem...

TBH I am also mystified by this failure.

I don't think the problem is the time it takes for the Linux kernel to
write the coredump.  As you can see, this test is using:

  <https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.base/segv.c>

Which is absurdly simple, and I don't think it would take more than 2
seconds to write a corefile for it.

As I said, I could not reproduce this failure on a PPC64 machine here.
I'll try to log into the buildslave and see if I can test directly from
there.

>>  gdb_continue_to_end
>>  
>> -# Checking $_exitcode.  It should be 0.
>> -gdb_test "print \$_exitcode" " = 0" \
>> -    "\$_exitcode is zero after normal inferior is executed"
>> +with_timeout_factor 10 {
>> +    # Checking $_exitcode.  It should be 0.
>> +    gdb_test "print \$_exitcode" " = 0" \
>> +	"\$_exitcode is zero after normal inferior is executed"
>>  
>> -# Checking $_exitsignal.  It should still be void, since the inferior
>> -# has not received any signal.
>> -gdb_test "print \$_exitsignal" " = void" \
>> -    "\$_exitsignal is still void after normal inferior is executed"
>> +    # Checking $_exitsignal.  It should still be void, since the inferior
>> +    # has not received any signal.
>> +    gdb_test "print \$_exitsignal" " = void" \
>> +	"\$_exitsignal is still void after normal inferior is executed"
>> +}
>> 
>
> This (many instances) doesn't make sense to me.  And I think wouldn't
> fix anything.  Seems to me the bumped timeout, if any, should be around
> the continue that caused the first time out:
>
> # Continue until the end.
> gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
>     "program terminated with SIGSEGV"

Sorry, I am confused...  The timeout does not occur on this command: it
occurs on the print commands.  So I think we must extend the timeout for
the print commands; don't we?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Pedro Alves]

On 08/25/2015 07:24 PM, Sergio Durigan Junior wrote:

>> This (many instances) doesn't make sense to me.  And I think wouldn't
>> fix anything.  Seems to me the bumped timeout, if any, should be around
>> the continue that caused the first time out:
>>
>> # Continue until the end.
>> gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
>>     "program terminated with SIGSEGV"
> 
> Sorry, I am confused...  The timeout does not occur on this command: it
> occurs on the print commands.  So I think we must extend the timeout for
> the print commands; don't we?

Not AFAICS from what you pasted.  The print time outs seem to me to be
cascading fails.  Highlighting what you pasted:

  (gdb) PASS: gdb.base/exitsignal.exp: $_exitcode is void before running
  continue
  Continuing.

  Program received signal SIGSEGV, Segmentation fault.
  0x00003fffb7cbf808 in .raise () from target:/lib64/libc.so.6
  (gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
  continue
  Continuing.
  FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV (timeout)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  print $_exitsignal
  FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after SIGSEGV. (timeout)
  print $_exitcode
  FAIL: gdb.base/exitsignal.exp: $_exitcode is still void after SIGSEGV (timeout)
  kill

  Program terminated with signal SIGSEGV, Segmentation fault.
  The program no longer exists.
  (gdb) print $_exitsignal
  $3 = 11
  (gdb) print $_exitcode
  $4 = void

That timed out waiting for the "Program terminated with signal SIGSEGV"
output.  Stripping the prints, we see it more clearly:

  Program received signal SIGSEGV, Segmentation fault.
  0x00003fffb7cbf808 in .raise () from target:/lib64/libc.so.6
  (gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
  continue
  Continuing.
  FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV (timeout)
  Program terminated with signal SIGSEGV, Segmentation fault.
  The program no longer exists.
  (gdb)

Thanks,
Pedro Alves

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Sergio Durigan Junior]

On Tuesday, August 25 2015, Pedro Alves wrote:

> On 08/25/2015 07:24 PM, Sergio Durigan Junior wrote:
>
>>> This (many instances) doesn't make sense to me.  And I think wouldn't
>>> fix anything.  Seems to me the bumped timeout, if any, should be around
>>> the continue that caused the first time out:
>>>
>>> # Continue until the end.
>>> gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
>>>     "program terminated with SIGSEGV"
>> 
>> Sorry, I am confused...  The timeout does not occur on this command: it
>> occurs on the print commands.  So I think we must extend the timeout for
>> the print commands; don't we?
>
> Not AFAICS from what you pasted.  The print time outs seem to me to be
> cascading fails.  Highlighting what you pasted:

Oh, you're right, I missed that (don't know how) when I was creating the
patch.  Thanks for the catch; I'll update the patch.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Pedro Alves]

On 08/25/2015 07:35 PM, Sergio Durigan Junior wrote:
> On Tuesday, August 25 2015, Pedro Alves wrote:
> 
>> On 08/25/2015 07:24 PM, Sergio Durigan Junior wrote:
>>
>>>> This (many instances) doesn't make sense to me.  And I think wouldn't
>>>> fix anything.  Seems to me the bumped timeout, if any, should be around
>>>> the continue that caused the first time out:
>>>>
>>>> # Continue until the end.
>>>> gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
>>>>     "program terminated with SIGSEGV"
>>>
>>> Sorry, I am confused...  The timeout does not occur on this command: it
>>> occurs on the print commands.  So I think we must extend the timeout for
>>> the print commands; don't we?
>>
>> Not AFAICS from what you pasted.  The print time outs seem to me to be
>> cascading fails.  Highlighting what you pasted:
> 
> Oh, you're right, I missed that (don't know how) when I was creating the
> patch.  Thanks for the catch; I'll update the patch.

I still don't think we should just bump the timeout for this without
understanding it better.  It very much looks like to me there's
a bug somewhere.  I see that it sometimes fails on the x86 buildbots too:

 http://gdb-build.sergiodj.net/builders/Fedora-x86_64-native-extended-gdbserver-m32/builds/1805

Thanks,
Pedro Alves

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Peter Schauer]

> I still don't think we should just bump the timeout for this without
> understanding it better.  It very much looks like to me there's
> a bug somewhere.  I see that it sometimes fails on the x86 buildbots too:
> 
>  http://gdb-build.sergiodj.net/builders/Fedora-x86_64-native-extended-gdbserver-m32/builds/1805

The timeout could be caused by Fedora ABRT processing.

What are you getting from
  cat /proc/sys/kernel/core_pattern
on the build slaves and on your local machines ?

-- 
Peter Schauer			Peter.Schauer@mytum.de

Re: [PATCH] Increase timeout on gdb.base/exitsignal.exp

[Sergio Durigan Junior]

On Tuesday, August 25 2015, Peter Schauer wrote:

>> I still don't think we should just bump the timeout for this without
>> understanding it better.  It very much looks like to me there's
>> a bug somewhere.  I see that it sometimes fails on the x86 buildbots too:
>> 
>>  http://gdb-build.sergiodj.net/builders/Fedora-x86_64-native-extended-gdbserver-m32/builds/1805
>
> The timeout could be caused by Fedora ABRT processing.
>
> What are you getting from
>   cat /proc/sys/kernel/core_pattern
> on the build slaves and on your local machines ?

Hm, that may be the reason indeed.  We're only seeing this on Fedora.
/proc/sys/kernel/core_pattern indeed invokes
/usr/libexec/abrt-hook-ccpp, which may be causing this since the
machines are generally under heavy load.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/