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]

Re: In latest cvs libc, test posix/wordexp-test fails


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]