The unit test runner relies on a NPTL behaviour that a spawned thread has the same PID as it's parent.
It does: 1) Fork 2) Exec runner again in child 3) Parent starts thread which waits on PID of (2) 4) Parent selects a pipe with a timeout to communicate with 3 Unfortunately this does not work with LinuxThreads since the thread started in 3 does not have the process forked in 2 as its child. LinuxThreads only allows a waitpid from the main thread of the parent. It's probably not a big issue since NPTL is the norm but it bit me. If you wanted to fix it you could fork twice (once for the test and once for the timeout) instead of starting a thread. From the parent do a wait instead of a waitpid and check which pid finished, the timeout one or the test one.I just rewrote it to wait without blocking and sleep but that was a nasty hack just to make progress quickly. On Tuesday, October 7, 2014 10:26:02 AM UTC+2, Saúl Ibarra Corretgé wrote: > > On 06/10/14 12:15, Martin Croome wrote: > > And I found the issue. The target uses Linuxthreads which will not > > support this scheme since pids are not shared with created processes. > > Bummer. > > > > I'm not exactly sure what problem you are running into :-/ Can you > elaborate? Is there anything libuv could do to help? > > > On Monday, October 6, 2014 11:04:50 AM UTC+2, Martin Croome wrote: > > > > I've narrowed down further. The problem seems related to waitpid > > being called inside a thread spawned from the parent. > > > > On Monday, October 6, 2014 10:41:00 AM UTC+2, Martin Croome wrote: > > > > I figured it out. Unfortunately there still seems to be this no > > child process issue. > > > > On Monday, October 6, 2014 10:14:46 AM UTC+2, Martin Croome > wrote: > > > > It seems like there is an install step that I'm missing > > where this script is run but this is make difficult by the > > fact that I'm cross compiling. > > > > make check obviously doesn't work since run-tests cannot > > work on my host. make tests/run-tests creates this libtool > > wrapper. I guess there is something inbetween. > > > > On Monday, October 6, 2014 10:07:00 AM UTC+2, Martin Croome > > wrote: > > > > Hi. Thanks for replying > > > > I'm using the configure .. make build route. The > > resulting run-tests binary has a libtool shell wrapper > > around it which fails on my target since the paths are > > all wrong. I saw the fixtures for the tests and have > > copied all of those into an appropriate structure on the > > target. I've tried compiling only the static libuv.a > > (using arguments to configure) and then it seems to work > > ok (i.e. I get an elf executable) but then on my target > > platform I get a bizarre error. Waitpid in run-tests > > always returns -1 (no child process) even though > > everything seems to work ok (fork, exec individual > > test). A normal fork exec waitpid process works on my > > target. I built a test program to verify that. > > > > I'm wondering whether I shouldn't abandon autotools and > > try to build with gyp. It is like looking for a needle > > in a haystack to figure out where things are going > wrong. > > > > > > On Monday, October 6, 2014 8:47:41 AM UTC+2, Saúl Ibarra > > Corretgé wrote: > > > > On 04/10/14 14:46, Martin Croome wrote: > > > Hi > > > > > > I wonder if someone could give me a little help > > cross compiling the > > > libuv unit tests. I'm using 1.0 and running into > > libtool/automake > > > issues. The tests are built as a libtool > > executable with stuck on script > > > and all the paths are wrong for my target. Is > > there any simple way to > > > force a normal binary to be built? > > > > > > > What issues are you running into? How are you > > cross-compiling libuv? The > > tests are compiled as a static binary, but some of > > them do depend on > > some fixture files and the libuv directory structure > > a bit. > > > > > > Cheers, > > > > -- > > Saúl Ibarra Corretgé > > http://bettercallsaghul.com > > > > -- > > You received this message because you are subscribed to the Google > > Groups "libuv" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To post to this group, send email to [email protected] > <javascript:> > > <mailto:[email protected] <javascript:>>. > > Visit this group at http://groups.google.com/group/libuv. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Saúl Ibarra Corretgé > http://bettercallsaghul.com > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
