[lsb-bugs] [Bug 1827] /tset/POSIX.os/procprim/exec/T.execl 30 FAIL on ia64 machine

bugzilla-daemon at linux-foundation.org bugzilla-daemon at linux-foundation.org
Tue Dec 11 19:14:51 PST 2007


http://bugs.linuxbase.org/show_bug.cgi?id=1827





--- Comment #1 from Zhang Kexin <kzhang at redhat.com>  2007-12-11 19:14:50 ---
Here is the Chat log, just a memo.

<licquia> 400|512 30 1 01:26:59|IC Start
<licquia> 200|512 30 01:26:59|TP Start
<licquia> 520|512 30 00014727 4 1|kill(pid, SIGCONT) did not cause delivery of
SIGCONT signal
<licquia> 520|512 30 00014727 4 2|expected action: process exitted - exit code
18
<licquia> 520|512 30 00014727 4 3|observed action: process exitted - exit code
0
<licquia> 220|512 30 1 01:26:59|FAIL
<licquia> 410|512 30 1 01:26:59|IC End
<mats> that one seems to have been a kerenel bug that should be well in the
past now
<licquia> test 30 is quite complex, so it's likely not related
<mats> oh, goody
<licquia> this is, i think, a timing issue, esp. since it seems not to trip
consistently
<licquia> here's the link to the source:
<licquia>
http://bzr.linux-foundation.org/lsb/devel/runtime-test?cmd=content;rev=cyeoh-20000829084105-87d4a67beef8baa9;pathrevid=pqm%40freestandards.org-20071210131624-v5do8youuf0tsd3d;path=modules/vsx-pcts/tset/POSIX.os/procprim/exec/exec1.c
<licquia> the actual error is about line 1133; the condition that caused it is
earlier
<mats> those links really don't help
<mats> I'll just look in my copy here
<mats> one disadvantage of the web front-ends to the dvcs's is these horrid
urls
<licquia> yup
<licquia> anyway, it looks like the test does fork-exec on a separate binary
<mats> hmmm, there's something about waitpid and LSB
<licquia> that binary does some stuff, then SIGSTOPs itself
<mats> I wonder....
<licquia> the parent process then SIGCONTs the child, and the child reports
which signal it got
<licquia> in the return value
<licquia> and that's what's borked: should return SIGSTOP's numeric value, but
returns zero instead
<licquia> unfortunately, the test isn't very clear on where the zero came from
<licquia> hmm, maybe
<mats> a little googling suggests SIGSTOP/SIGCONT is a little murky...
<licquia> how so?
<mats> reading... so far cases don't look like they apply
<licquia> hmm
<mats> e.g. http://lkml.org/lkml/2006/7/3/133
<licquia> problem is, i can't see now how timing could be an issue unless
kill(getpid(), SIGSTOP) somehow failed
<licquia> but even that should be caught with a previous condition
<licquia> because if the child couldn't stop, it would run on and exit, which
one would think would be caught earlier
<licquia> (basically, it does waitpid() with a timeout, and expects to reach
that timeout)
* cr3 (~cr3 at bas5-montreal02-1167963721.dsl.bell.ca) has joined #lsb
<licquia> looking at the code, it looks like the child actually stops
<licquia> because we check for that
<licquia> then we try to SIGKILL, which fails with EPERM
<licquia> and that works, because we check for that too
<licquia> *then* we send SIGCONT
<licquia> the signal gets sent
<licquia> then we waitpid() for the child
<licquia> we check if the child exited, and why
<licquia> that check is what fails
<licquia> and, according to the test, the observed action is that the return
value is zero
<licquia> which, looking at the child's code, doesn't look possible
<licquia> unless... it's the sigaction() call which is failing in the child...


-- 
Configure bugmail: http://bugs.linuxbase.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the lsb-bugs mailing list