clone03/06 randomly crashing
Hi,
I'm occasionally getting core files from clone03/clone06 testcases. The testcase itself gives PASS, it is the child which is randomly crashing. It seems to occur more on single cpu systems.
For example:
Core was generated by `clone03'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000402bfd in tst_print (tcid=0x403d0e "clone03", tnum=1, ttype=2,
tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412
412 {
(gdb) bt
#0 0x0000000000402bfd in tst_print (tcid=0x403d0e "clone03", tnum=1, ttype=2,
tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412
#1 0x00000000004031be in tst_res (ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#2 0x0000000000403761 in tst_brk (ttype=2, fname=0x0, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640
#3 0x0000000000403960 in tst_brkm (ttype=2, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698
#4 0x0000000000403b45 in def_handler (sig=15) at tst_sig.c:248
#5 <signal handler called>
#6 0x00000037940db650 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
#7 0x000000000040169e in child_fn () at clone03.c:208
#8 0x00000037940e890d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115Dump of assembler code for function tst_print:
0x0000000000402bd0 <+0>: mov %rbx,-0x30(%rsp)
0x0000000000402bd5 <+5>: mov %rbp,-0x28(%rsp)
0x0000000000402bda <+10>: mov %edx,%ebx 0x0000000000402bdc <+12>: mov %r12,-0x20(%rsp) 0x0000000000402be1 <+17>: mov %r13,-0x18(%rsp) 0x0000000000402be6 <+22>: mov %rdi,%r12 0x0000000000402be9 <+25>: mov %r14,-0x10(%rsp) 0x0000000000402bee <+30>: mov %r15,-0x8(%rsp) 0x0000000000402bf3 <+35>: sub $0x2858,%rsp 0x0000000000402bfa <+42>: mov %esi,%r14d => 0x0000000000402bfd <+45>: mov %rcx,0x18(%rsp)
(gdb) p $rsp
$1 = (void *) 0x14c3800
(gdb) x/1x $rsp0x14c3800: Cannot access memory at address 0x14c3800
It looks like it receives SIGTERM and while handling SIGTERM it hits SIGSEGV. I don't know what is source of that SIGTERM. I was looking into the second part and looks like the stack for child is not large enough.
I modified clone03.c (see attached clone03_poison.patch) to get some extra empty buffer before the child's stack, which was set to pattern 0xDE.
Before:
|-------------------------------|
child_stack child_stack+CHILD_STACK_SIZE
After:
|---------------------|-------------------------------|
poision_start child_stack child_stack+CHILD_STACK_SIZENow if I start clone03 and kill it I can randomly reproduce the SIGSEGV (attached clone03_kill.sh). The backtrace usually looks like:
... (random place)
#5 0x000000000040324e in tst_res (ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316 #6 0x00000000004037f1 in tst_brk (ttype=2, fname=0x0, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #7 0x00000000004039f0 in tst_brkm (ttype=2, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698 #8 0x0000000000403bd5 in def_handler (sig=13) at tst_sig.c:248 #9 <signal handler called>
#10 0x0000003327cdb650 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 #11 0x000000000040172e in child_fn () at clone03.c:212
#12 0x0000003327ce890d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) p poison_start
$1 = (void *) 0xa02010
(gdb) p child_stack
$2 = (void *) 0xa03010
(gdb) x/16x poison_start0xa02010: 0xdededede 0xdededede 0xdededede 0xdededede0xa02020: 0xdededede 0xdededede 0xdededede 0xdededede0xa02030: 0xdededede 0xdededede 0xdededede 0xdededede0xa02040: 0xdededede 0xdededede 0xdededede 0xdededede
...
(gdb)0xa02490: 0xdededede 0xdededede 0xdededede 0xdededede0xa024a0: 0x00000018 0x00000030 0x00a02800 0x000000000xa024b0: 0x00a02740 0x00000000 0xdededede 0xdededede0xa024c0: 0xdededede 0xdededede 0x27409296 0x00000033
The above shows that 0xDE pattern has been overwritten.
Extending child stack helps with the second part: SIGSEGV #define CHILD_STACK_SIZE 16384*4
but I have no idea, where is that first SIGTERM coming from. Any ideas?
Regards,
Jan
testcases/kernel/syscalls/clone/clone03.c +8 -3
@@ -87,13 +87,15 @@ static int pfd[2];char *TCID ="clone03" ;/* Test program identifier. */ int TST_TOTAL =1 ;/* Total number of test cases. */ +void *poison_start;/* stack for child */ +void *child_stack;/* stack for child */ +#define POISON_SIZE getpagesize()int main (int ac,char **av) {int lc;char *msg; -void *child_stack;/* stack for child */ char buff[10 ];int child_pid;
@@ -104,10 +106,13 @@ int main(int ac, char **av)setup ();/* Allocate stack for child */ -if ((child_stack = (void *)malloc (CHILD_STACK_SIZE )) ==NULL ) { +if ((poison_start = (void *)malloc (POISON_SIZE +CHILD_STACK_SIZE )) ==NULL ) {tst_brkm (TBROK , cleanup,"Cannot allocate stack for child" ); } +memset (poison_start,0xDE ,POISON_SIZE ); + child_stack = poison_start +POISON_SIZE ; +for (lc =0 ;TEST_LOOPING (lc); lc++) { Tst_count =0 ;
@@ -154,7 +159,7 @@ int main(int ac, char **av) } -free (child_stack); +free (poison_start);cleanup ();tst_exit ();
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
----- Original Message -----
Quoted 112 lines
From: "Jan Stancek" <[email protected]>
To: [email protected]
Cc: "Jeffrey Burke" <[email protected]>
Sent: Friday, 30 November, 2012 3:37:03 PM
Subject: [LTP] clone03/06 randomly crashingHi,
I'm occasionally getting core files from clone03/clone06 testcases. The testcase itself gives PASS, it is the child which is randomly crashing.
It seems to occur more on single cpu systems.For example:
Core was generated by `clone03'.
Program terminated with signal 11, Segmentation fault.
#00x0000000000402bfdintst_print(tcid=0x403d0e "clone03", tnum=1, ttype=2,tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412412 {
(gdb) bt
#00x0000000000402bfdintst_print(tcid=0x403d0e "clone03", tnum=1, ttype=2,tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412#1
0x00000000004031beintst_res(ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#20x0000000000403761intst_brk(ttype=2, fname=0x0, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #30x0000000000403960intst_brkm(ttype=2, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698#4 0x0000000000403b45 in def_handler (sig=15) at tst_sig.c:248 #5 <signal handler called> #6 0x00000037940db650 in __write_nocancel () at
../sysdeps/unix/syscall-template.S:82
#70x000000000040169einchild_fn() at clone03.c:208 #80x00000037940e890din clone () at../sysdeps/unix/sysv/linux/x86_64/clone.S:115Dump of assembler code for function
tst_print:0x0000000000402bd0 <+0>: mov %rbx,-0x30(%rsp) 0x0000000000402bd5 <+5>: mov %rbp,-0x28(%rsp) 0x0000000000402bda <+10>: mov %edx,%ebx 0x0000000000402bdc <+12>: mov %r12,-0x20(%rsp) 0x0000000000402be1 <+17>: mov %r13,-0x18(%rsp) 0x0000000000402be6 <+22>: mov %rdi,%r12 0x0000000000402be9 <+25>: mov %r14,-0x10(%rsp) 0x0000000000402bee <+30>: mov %r15,-0x8(%rsp) 0x0000000000402bf3 <+35>: sub $0x2858,%rsp 0x0000000000402bfa <+42>: mov %esi,%r14d=>
0x0000000000402bfd<+45>: mov %rcx,0x18(%rsp)(gdb) p $rsp
$1 = (void *)0x14c3800
(gdb) x/1x $rsp0x14c3800: Cannot access memory at address0x14c3800It looks like it receives SIGTERM and while handling SIGTERM it hits SIGSEGV.
I don't know what is source of that SIGTERM. I was looking into the second part
and looks like the stack for child is not large enough.I modified
clone03.c(see attached clone03_poison.patch) to get some extra
empty buffer before the child's stack, which was set to pattern0xDE.Before:
|-------------------------------| child_stack child_stack+CHILD_STACK_SIZE After: |---------------------|-------------------------------| poision_start child_stackchild_stack+CHILD_STACK_SIZE
Now if I start clone03 and kill it I can randomly reproduce the SIGSEGV (attached
clone03_kill.sh).
The backtrace usually looks like:
... (random place)
#50x000000000040324eintst_res(ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#60x00000000004037f1intst_brk(ttype=2, fname=0x0, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #70x00000000004039f0intst_brkm(ttype=2, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698
#80x0000000000403bd5indef_handler(sig=13) at tst_sig.c:248 #9 <signal handler called>
#100x0000003327cdb650in__write_nocancel() at../sysdeps/unix/syscall-template.S:82
#110x000000000040172einchild_fn() at clone03.c:212
#120x0000003327ce890din clone () at../sysdeps/unix/sysv/linux/x86_64/clone.S:115(gdb) p
poison_start
$1 = (void *)0xa02010
(gdb) pchild_stack
$2 = (void *)0xa03010(gdb) x/16x
poison_start0xa02010:0xdededede0xdededede0xdededede0xdededede0xa02020:0xdededede0xdededede0xdededede0xdededede0xa02030:0xdededede0xdededede0xdededede0xdededede0xa02040:0xdededede0xdededede0xdededede0xdededede
...
(gdb)0xa02490:0xdededede0xdededede0xdededede0xdededede0xa024a0:0x000000180x000000300x00a028000x000000000xa024b0:0x00a027400x000000000xdededede0xdededede0xa024c0:0xdededede0xdededede0x274092960x00000033
Quoted 6 lines
The above shows that
0xDEpattern has been overwritten.Extending child stack helps with the second part: SIGSEGV #define
CHILD_STACK_SIZE16384*4
but I have no idea, where is that first SIGTERM coming from. Any ideas?
It appears to be ltp-pan, which sees the child as orphan. When I added "-d 511", I've got some additional output:
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no cutime=0 cstime=0
<<<test_end>>>
pids still running:
orphans still running: -26125 clone03 1 TBROK : unexpected signal 15 received (pid = 26126). clone03 2 TBROK : Remaining cases broken
pan was signaled with sig 2...
propagating sig 2 to orphaned pgrp -26125
orphans still running:
I'll send a patch, that adds wait() to parent.
Regards,
Jan
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 135 lines · Jan Stancek
----- Original Message -----
Quoted 112 lines
From: "Jan Stancek" <[email protected]>
To: [email protected]
Cc: "Jeffrey Burke" <[email protected]>
Sent: Friday, 30 November, 2012 3:37:03 PM
Subject: [LTP] clone03/06 randomly crashingHi,
I'm occasionally getting core files from clone03/clone06 testcases. The testcase itself gives PASS, it is the child which is randomly crashing.
It seems to occur more on single cpu systems.For example:
Core was generated by `clone03'.
Program terminated with signal 11, Segmentation fault.
#00x0000000000402bfdintst_print(tcid=0x403d0e "clone03", tnum=1, ttype=2,tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412412 {
(gdb) bt
#00x0000000000402bfdintst_print(tcid=0x403d0e "clone03", tnum=1, ttype=2,tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412#1
0x00000000004031beintst_res(ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#20x0000000000403761intst_brk(ttype=2, fname=0x0, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #30x0000000000403960intst_brkm(ttype=2, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698#4 0x0000000000403b45 in def_handler (sig=15) at tst_sig.c:248 #5 <signal handler called> #6 0x00000037940db650 in __write_nocancel () at
../sysdeps/unix/syscall-template.S:82
#70x000000000040169einchild_fn() at clone03.c:208 #80x00000037940e890din clone () at../sysdeps/unix/sysv/linux/x86_64/clone.S:115Dump of assembler code for function
tst_print:0x0000000000402bd0 <+0>: mov %rbx,-0x30(%rsp) 0x0000000000402bd5 <+5>: mov %rbp,-0x28(%rsp) 0x0000000000402bda <+10>: mov %edx,%ebx 0x0000000000402bdc <+12>: mov %r12,-0x20(%rsp) 0x0000000000402be1 <+17>: mov %r13,-0x18(%rsp) 0x0000000000402be6 <+22>: mov %rdi,%r12 0x0000000000402be9 <+25>: mov %r14,-0x10(%rsp) 0x0000000000402bee <+30>: mov %r15,-0x8(%rsp) 0x0000000000402bf3 <+35>: sub $0x2858,%rsp 0x0000000000402bfa <+42>: mov %esi,%r14d=>
0x0000000000402bfd<+45>: mov %rcx,0x18(%rsp)(gdb) p $rsp
$1 = (void *)0x14c3800
(gdb) x/1x $rsp0x14c3800: Cannot access memory at address0x14c3800It looks like it receives SIGTERM and while handling SIGTERM it hits SIGSEGV.
I don't know what is source of that SIGTERM. I was looking into the second part
and looks like the stack for child is not large enough.I modified
clone03.c(see attached clone03_poison.patch) to get some extra
empty buffer before the child's stack, which was set to pattern0xDE.Before:
|-------------------------------| child_stack child_stack+CHILD_STACK_SIZE After: |---------------------|-------------------------------| poision_start child_stackchild_stack+CHILD_STACK_SIZE
Now if I start clone03 and kill it I can randomly reproduce the SIGSEGV (attached
clone03_kill.sh).
The backtrace usually looks like:
... (random place)
#50x000000000040324eintst_res(ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#60x00000000004037f1intst_brk(ttype=2, fname=0x0, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #70x00000000004039f0intst_brkm(ttype=2, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698
#80x0000000000403bd5indef_handler(sig=13) at tst_sig.c:248 #9 <signal handler called>
#100x0000003327cdb650in__write_nocancel() at../sysdeps/unix/syscall-template.S:82
#110x000000000040172einchild_fn() at clone03.c:212
#120x0000003327ce890din clone () at../sysdeps/unix/sysv/linux/x86_64/clone.S:115(gdb) p
poison_start
$1 = (void *)0xa02010
(gdb) pchild_stack
$2 = (void *)0xa03010(gdb) x/16x
poison_start0xa02010:0xdededede0xdededede0xdededede0xdededede0xa02020:0xdededede0xdededede0xdededede0xdededede0xa02030:0xdededede0xdededede0xdededede0xdededede0xa02040:0xdededede0xdededede0xdededede0xdededede
...
(gdb)0xa02490:0xdededede0xdededede0xdededede0xdededede0xa024a0:0x000000180x000000300x00a028000x000000000xa024b0:0x00a027400x000000000xdededede0xdededede0xa024c0:0xdededede0xdededede0x274092960x00000033Quoted 6 lines
The above shows that
0xDEpattern has been overwritten.Extending child stack helps with the second part: SIGSEGV #define
CHILD_STACK_SIZE16384*4
but I have no idea, where is that first SIGTERM coming from. Any ideas?It appears to be ltp-pan, which sees the child as orphan. When I added "-d 511", I've got some additional output:
<<<
execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no cutime=0 cstime=0
<<<test_end>>>
pids still running:orphans still running: -26125 clone03 1 TBROK : unexpected signal 15 received (pid = 26126). clone03 2 TBROK : Remaining cases broken
Quoted 8 lines
pan was signaled with sig 2...
propagating sig 2 to orphaned pgrp -26125
orphans still running:I'll send a patch, that adds
wait()to parent.Regards,
Jan
Hi Jan,
I think you're right. We have hit similar problems with setrlimit01, and few other tests.
Unfortunately we did not upstream these patches as we are still working with an older LTP.
I'll try to rebase it and share some other pending patches we are using in our project.
Regards,
Carmelo
Quoted 11 lines
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 149 lines · Carmelo AMOROSO
Quoted 135 lines · Jan Stancek
----- Original Message -----
Quoted 112 lines
From: "Jan Stancek" <[email protected]>
To: [email protected]
Cc: "Jeffrey Burke" <[email protected]>
Sent: Friday, 30 November, 2012 3:37:03 PM
Subject: [LTP] clone03/06 randomly crashingHi,
I'm occasionally getting core files from clone03/clone06 testcases. The testcase itself gives PASS, it is the child which is randomly crashing.
It seems to occur more on single cpu systems.For example:
Core was generated by `clone03'.
Program terminated with signal 11, Segmentation fault.
#00x0000000000402bfdintst_print(tcid=0x403d0e "clone03", tnum=1, ttype=2,tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412412 {
(gdb) bt
#00x0000000000402bfdintst_print(tcid=0x403d0e "clone03", tnum=1, ttype=2,tmesg=0x14c6070 "unexpected signal 15 received (pid = 17427).") at tst_res.c:412#1
0x00000000004031beintst_res(ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#20x0000000000403761intst_brk(ttype=2, fname=0x0, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #30x0000000000403960intst_brkm(ttype=2, func=0x4013d0 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698#4 0x0000000000403b45 in def_handler (sig=15) at tst_sig.c:248 #5 <signal handler called> #6 0x00000037940db650 in __write_nocancel () at
../sysdeps/unix/syscall-template.S:82
#70x000000000040169einchild_fn() at clone03.c:208 #80x00000037940e890din clone () at../sysdeps/unix/sysv/linux/x86_64/clone.S:115Dump of assembler code for function
tst_print:0x0000000000402bd0 <+0>: mov %rbx,-0x30(%rsp) 0x0000000000402bd5 <+5>: mov %rbp,-0x28(%rsp) 0x0000000000402bda <+10>: mov %edx,%ebx 0x0000000000402bdc <+12>: mov %r12,-0x20(%rsp) 0x0000000000402be1 <+17>: mov %r13,-0x18(%rsp) 0x0000000000402be6 <+22>: mov %rdi,%r12 0x0000000000402be9 <+25>: mov %r14,-0x10(%rsp) 0x0000000000402bee <+30>: mov %r15,-0x8(%rsp) 0x0000000000402bf3 <+35>: sub $0x2858,%rsp 0x0000000000402bfa <+42>: mov %esi,%r14d=>
0x0000000000402bfd<+45>: mov %rcx,0x18(%rsp)(gdb) p $rsp
$1 = (void *)0x14c3800
(gdb) x/1x $rsp0x14c3800: Cannot access memory at address0x14c3800It looks like it receives SIGTERM and while handling SIGTERM it hits SIGSEGV.
I don't know what is source of that SIGTERM. I was looking into the second part
and looks like the stack for child is not large enough.I modified
clone03.c(see attached clone03_poison.patch) to get some extra
empty buffer before the child's stack, which was set to pattern0xDE.Before:
|-------------------------------| child_stack child_stack+CHILD_STACK_SIZE After: |---------------------|-------------------------------| poision_start child_stackchild_stack+CHILD_STACK_SIZE
Now if I start clone03 and kill it I can randomly reproduce the SIGSEGV (attached
clone03_kill.sh).
The backtrace usually looks like:
... (random place)
#50x000000000040324eintst_res(ttype=2, fname=<value optimized out>, arg_fmt=<value optimized out>) at tst_res.c:316
#60x00000000004037f1intst_brk(ttype=2, fname=0x0, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:640 #70x00000000004039f0intst_brkm(ttype=2, func=0x401420 <cleanup>, arg_fmt=<value optimized out>) at tst_res.c:698
#80x0000000000403bd5indef_handler(sig=13) at tst_sig.c:248 #9 <signal handler called>
#100x0000003327cdb650in__write_nocancel() at../sysdeps/unix/syscall-template.S:82
#110x000000000040172einchild_fn() at clone03.c:212
#120x0000003327ce890din clone () at../sysdeps/unix/sysv/linux/x86_64/clone.S:115(gdb) p
poison_start
$1 = (void *)0xa02010
(gdb) pchild_stack
$2 = (void *)0xa03010(gdb) x/16x
poison_start0xa02010:0xdededede0xdededede0xdededede0xdededede0xa02020:0xdededede0xdededede0xdededede0xdededede0xa02030:0xdededede0xdededede0xdededede0xdededede0xa02040:0xdededede0xdededede0xdededede0xdededede
...
(gdb)0xa02490:0xdededede0xdededede0xdededede0xdededede0xa024a0:0x000000180x000000300x00a028000x000000000xa024b0:0x00a027400x000000000xdededede0xdededede0xa024c0:0xdededede0xdededede0x274092960x00000033Quoted 6 lines
The above shows that
0xDEpattern has been overwritten.Extending child stack helps with the second part: SIGSEGV #define
CHILD_STACK_SIZE16384*4
but I have no idea, where is that first SIGTERM coming from. Any ideas?It appears to be ltp-pan, which sees the child as orphan. When I added "-d 511", I've got some additional output:
<<<
execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no cutime=0 cstime=0
<<<test_end>>>
pids still running:orphans still running: -26125 clone03 1 TBROK : unexpected signal 15 received (pid = 26126). clone03 2 TBROK : Remaining cases brokenQuoted 8 lines
pan was signaled with sig 2...
propagating sig 2 to orphaned pgrp -26125
orphans still running:I'll send a patch, that adds
wait()to parent.Regards,
JanHi Jan,
I think you're right. We have hit similar problems with setrlimit01, and few other tests.
Quoted 5 lines
Unfortunately we did not upstream these patches as we are still working with an older LTP.
I'll try to rebase it and share some other pending patches we are using in our project.
Sounds great, thank you very much.
Regards,
Wanlong Gao
Quoted 17 lines
Regards,
CarmeloQuoted 11 lines
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 9 lines
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Hi!
Quoted 22 lines
Quoted 13 lines
It appears to be ltp-pan, which sees the child as orphan. When I added "-d 511", I've got some additional output:
<<<
execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no cutime=0 cstime=0
<<<test_end>>>
pids still running:orphans still running: -26125 clone03 1 TBROK : unexpected signal 15 received (pid = 26126). clone03 2 TBROK : Remaining cases brokenQuoted 8 lines
pan was signaled with sig 2...
propagating sig 2 to orphaned pgrp -26125
orphans still running:I'll send a patch, that adds
wait()to parent.Regards,
Jan
Quoted 6 lines
Hi Jan,
I think you're right. We have hit similar problems with setrlimit01, and few other tests.Unfortunately we did not upstream these patches as we are still working with an older LTP.
Is there any reason for that? I try not to break anything and stay as backward compatible as possible. I know that for maintenance people usually use the version that was used for release testing and stick to this through the product life cycle.
Anyway if there are some changes or bugs that prevents you from using up to date LTP please let us know.
Quoted 2 lines
I'll try to rebase it and share some other pending patches we are using in our project.
I'm looking forward to see the patches.
Signature · 13 lines
Cyril Hrubis [email protected] ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list