Glibc Timeout errors - revisited
Bill's LFS Login
lfsbill at wlmcs.com
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:
> >>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.
> > 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:
> >>/mnt/lfs/usr/src/cvs-20030603/glibc-build/rt/tst-shm >
> > 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.
lfsbill at wlmcs.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev