This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tue, 2003-11-18 at 00:32, Martin Schlemmer wrote: > On Mon, 2003-11-17 at 00:51, Martin Schlemmer wrote: > > On Sun, 2003-11-16 at 21:07, Martin Schlemmer wrote: > > > On Sun, 2003-11-16 at 19:41, Andreas Jaeger wrote: > > > > Martin Schlemmer <azarah@nosferatu.za.org> writes: > > > > > > > > > On Sun, 2003-11-16 at 18:52, Andreas Jaeger wrote: > > > > >> Martin Schlemmer <azarah@nosferatu.za.org> writes: > > > > >> > > > > >> > Hi > > > > >> > > > > > >> > In latest cvs checkout, the posix/wordexp-test test fails. > > > > >> > > > > >> It does not fail for me. What platform is this? > > > > >> > > > > > > > > > > i686-pc-linux-gnu > > > > > > > > Same for me. > > > > > > > > > Could this be a gcc issue ? > > > > > > > > Could be but for that we need more details... Which compiler version > > > > do you use? > > > > > > > > > > Ok, originally used 20031106 of the gcc-3_3-rhl-branch branch, > > > then tried 20031022 which worked fine with prev glibc checkouts. > > > The same outcome though. I will backtrack glibc a bit and just > > > verify that it did work fine on older snapshots. > > > > > > > Backtracked glibc and gcc, but still this issue. Any ideas what > > else could cause this ? Kernel ? > > > > Ok, I build an entire system with the same versions of all packages in > chroot, and that works just fine. > <snip> > So it basically seems as something apart from glibc (or something glibc > specific but slightly different like environment, etc) causes the > failings. > > A snippit of a strace on the failing tests (test 14 of wordexp-test) > gives the following (I can include the whole thing if needed): > > -- > write(1, "Test 13 ($var): OK\n", 19Test 13 ($var): OK > ) = 19 <snip> > clone(Process 7052 attached > child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x401562c8) = 7052 > [pid 7052] dup2(-1, 1) = -1 EBADF (Bad file descriptor) > [pid 7052] close(-1) = -1 EBADF (Bad file descriptor) > [pid 7052] close(2) = 0 > [pid 7052] open("/dev/null", O_WRONLY) = 2 > [pid 7052] fstat64(2, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0 > [pid 7052] exit_group(90) = ? > Process 7052 detached > --- SIGCHLD (Child exited) @ 0 (0) --- > waitpid(7052, [WIFEXITED(s) && WEXITSTATUS(s) == 90], 0) = 7052 > write(1, "Test 14 ($(echo :abc:)): FAILED\n", 32Test 14 ($(echo :abc:)): > FAILED > ) = 32 > -- > Ok, for those interested, seems like it was some weirdness in /dev. I have not tried to track it that far, but it seems its my initial workaround for udev - I use a tarball and ramfs to save /dev state. The issue however I guess is that the tarball on reboot/halt was created with my user still 'console user', so when the system booted again, root did not own /dev/*, and wierd things happened. Cheers, -- Martin Schlemmer
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |