Hi,
I installed some kernel patch (grsecurity) which, among other things, has a feature to randomize pids (so never ever child will get a pid which is ppid + 1). Perhaps, this is the reason that during following test (test 10102, line 9153 from 7.4.44 - 7.5 cvs test is on the way): object proc = Process.create_process (({"/bin/sleep", "99999"})); array threads = allocate (10, Thread.thread_create) ( lambda (object proc) {proc->wait();}, proc); sleep (1); proc->kill (9); return threads->wait() - ({-1});
...the verify process hung... The only reason what I may think of is dependency on PID generation order (this is, actually, only visible change - previously, I compiled and verified pike installation on same computer without any problems, and when I disable randomized PIDs, this test passes quickly).
NB: after some time, it fails with: [WATCHDOG] Pike testsuite timeout, sending SIGABRT.
Any ideas how to make it independent from PIDs? :)
Regards, /Al
I installed some kernel patch (grsecurity) which, among other things, has a feature to randomize pids (so never ever child will get a pid which is ppid + 1).
Perhaps, this is the reason that during following test (test 10102, line 9153 from 7.4.44 - 7.5 cvs test is on the way):
object proc = Process.create_process (({"/bin/sleep", "99999"})); array threads = allocate (10, Thread.thread_create) ( lambda (object proc) {proc->wait();}, proc); sleep (1); proc->kill (9); return threads->wait() - ({-1});
...the verify process hung... The only reason what I may think of is dependency on PID generation order (this is, actually, only visible change - previously, I compiled and verified pike installation on same computer without any problems, and when I disable randomized PIDs, this test passes quickly).
The test as such has no dependency on the PID generation order; it might however be that your thread library has such dependencies.
Regards, /Al
/ Henrik Grubbström (Lysator)
Previous text:
2004-03-15 12:15: Subject: make verify hung (randomized pids problem?)
Hi,
I installed some kernel patch (grsecurity) which, among other things, has a feature to randomize pids (so never ever child will get a pid which is ppid + 1).
Perhaps, this is the reason that during following test (test 10102, line 9153 from 7.4.44 - 7.5 cvs test is on the way):
object proc = Process.create_process (({"/bin/sleep", "99999"})); array threads = allocate (10, Thread.thread_create) ( lambda (object proc) {proc->wait();}, proc); sleep (1); proc->kill (9); return threads->wait() - ({-1});
...the verify process hung... The only reason what I may think of is dependency on PID generation order (this is, actually, only visible change - previously, I compiled and verified pike installation on same computer without any problems, and when I disable randomized PIDs, this test passes quickly).
NB: after some time, it fails with:
[WATCHDOG] Pike testsuite timeout, sending SIGABRT.
Any ideas how to make it independent from PIDs? :)
Regards, /Al
/ Brevbäraren
On Mon, Mar 15, 2004 at 01:00:04PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
The test as such has no dependency on the PID generation order; it might however be that your thread library has such dependencies.
Hmmm... This is standard library included with SuSe Linux... I'll into this later... However, I guess that if this would be the case, I would notice it long time ago (I've production server running more than 6 month with this feature).
BTW, in 7.5-cvs this problem still exists - with random pids it hangs (test 316, line 800 - same test), without - everything is OK.
May be you right - that the problem is in thread library, but why it shows up only during pike tests?
Regards, /Al
Pike has more thorough tests on its environments than do most other projects -- possibly most to be attributed to that we don't like to spend time tracking down problems in Pike that were really invented elsewhere.
(So large chunks of the testsuite test for bugs in the environment that would make Pike behave wrong when put to some tasks due to flaws outside of our reach.)
/ Johan Sundström (Achtung Liebe!)
Previous text:
2004-03-15 13:14: Subject: Re: make verify hung (randomized pids problem?)
On Mon, Mar 15, 2004 at 01:00:04PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
The test as such has no dependency on the PID generation order; it might however be that your thread library has such dependencies.
Hmmm... This is standard library included with SuSe Linux... I'll into this later... However, I guess that if this would be the case, I would notice it long time ago (I've production server running more than 6 month with this feature).
BTW, in 7.5-cvs this problem still exists - with random pids it hangs (test 316, line 800 - same test), without - everything is OK.
May be you right - that the problem is in thread library, but why it shows up only during pike tests?
Regards, /Al
/ Brevbäraren
On Mon, Mar 15, 2004 at 01:30:01PM +0100, Johan Sundström (Achtung Liebe!) @ Pike (-) developers forum wrote:
(So large chunks of the testsuite test for bugs in the environment that would make Pike behave wrong when put to some tasks due to flaws outside of our reach.)
OK... So I did another test... Just extracted this one (failing) from testsuite and run it directly (using same pike binary, which was just built)... 100 passes... No single hung.
The question - where is the catch? It it would be a bug in threads library, it would show up both in testsuite and during regular run, or?
Perhaps, the testsuite handler (driver) is expecting some specific pid order, or something like this?
Regards, /Al
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum