Glibc Timeout errors - revisited

Bill's LFS Login lfsbill at
Sat Jul 5 02:39:14 PDT 2003

On Fri, 4 Jul 2003, James Robertson wrote:

> Bill's LFS Login wrote:
> > On Fri, 4 Jul 2003, James Robertson wrote:
> >><snip>

> >>
> >>

> >>I am getting a timeout error from Glibc in Ch5.  My issue is that I can
> >>repeat it every time I run make check from fresh build (of glibc).  I
> >>always get through if I re-run make check a second time [...] I have
> >> searched Google and the glibc-* mailing lists [...] (Google even
> >> brings up our lists first! - I thought that was kinda cool.) and
> >>came up empty.<snip>

> > I don't think timeout will affect this test, after looking at the code.
> >
> >>My question - I was thinking of posting a question to one of the glibc
> >>lists about this issue.  <snip>

> > I found this after looking at the C code for the shared memory test. But
> > I don't see it failing on first attempt and working on the second. But I
> > thought I would pass it on "just in case". From man shm_open:
> >
> >    The POSIX shared memory object implementation on Linux 2.4 makes use
> >    of  a  dedicated  file  system,  which  is  normally  mounted
> >    under /dev/shm.
> <snip>

> > So, I just wanted to mention to make sure you have a mount of tmpfs on
> > /dev/shm done before you post to those folks.<snip>

> what would that mount command lool like?
> mount -t tmpfs [device] /dev/shm
> What is the [device]?  I looked in man mount for the tmpfs and found
> nothing helpful.

I see Erika gave the Documents ref to you, but in case you didn't figure
it out from that stuff, the "device" (it's really a psuedo-device, like
proc and devpts) is tmpfs.

BTW, because of the great utility of the Sys V IPC stuff, most systems
have it enabled. And for GNU/Linux systems, an fstab entry like the
following is used

    tmpfs /dev/shm tmpfs defaults 0 0

> > <snip>

> > NOTE: some theorizing going on below - no "gospelization" should be
> > assigned to it. My ignorance knows no bounds.

> > Note that the second attempt *should* always succeed *if* the first test
> > creates shared memory successfully and then aborts *without* releasing
> > the memory (use ipcs to check this possibility - see below). This is be-
> > cause the second try fails to creat the (already existing) shared memory
> > handle, sees the error and says "that's OK" (to itself), puts a message
> > in the log and returns 0.
> This may be it.  The test *always" succeeds the second time.  I have ran
> throught it 4 times just to make sure.  I will go ahead do it a 5th time
> and use your help following with the ipcs deal.
> > You can use ipcs -m (man ipcs for additional info) to examine shared
> > memory attributes. If you see this *between* attempts, additional
> > credence can be assigned to the "second attempt always succeeds".
> > This might also argue for the scheduling/nanosleep theories.
> >
> >>Here is my error and the last few lines of code:
> >>
> >><snip>
> >
> >>/mnt/lfs/usr/src/cvs-20030603/glibc-build/rt/tst-shm  >
> >>/mnt/lfs/usr/src/cvs-20030603/glibc-build/rt/tst-shm.out
> >
> > The above file may yield some more clues (especially after the first
> > attempt).
> >
> I'll post this file next time, if it turns out to be usefull.  Stupid me
> deleted the tree a couple minutes ago before going for try #5. Doh!

> > I hope the above helps when posting to the libc folks.
> >
> Thanks Bill.  I'll see what I can figure out.

Bill Maltby
lfsbill at
Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list