bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bash-3.2.39] race condition on AIX when using libtool with bash


From: Michael Haubenwallner
Subject: [bash-3.2.39] race condition on AIX when using libtool with bash
Date: Wed, 30 Jul 2008 18:53:41 +0200

Hi,

have some strange race condition here on aix5.3 with bash-3.2.39, when
using CONFIG_SHELL=/path/to/bash, building in parallel (-j16) with
libtool. It works when using /bin/ksh.

Sporadically there are two lines missing in the libtool-generated
'file.lo', while other files in the same build directory contain these
lines. The broken files are different ones amongst different runs of the
same package build - and sometimes it does not happen at all.

The missing lines are from this command sequence in libtool-1.5.26:

http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=blob;f=ltmain.in;h=48facb91640a8fd43ad0e7ce4139ec0ccb4bfa09;hb=branch-1-5#l1004
1004       test -z "$run" && cat >> ${libobj}T <<EOF
1005 pic_object='$objdir/$objname'
1006 
1007 EOF

There are three such writes to the same file in libtool, this one being
the one with the smallest content.

As a result, when linking this file.lo into some lib.la, libtool spits:

        libtool: link: cannot find name of object for `GetWMCMapW.lo'

This error can only come either from [2] or [3].
[2] 
http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=blob;f=ltmain.in;h=48facb91640a8fd43ad0e7ce4139ec0ccb4bfa09;hb=branch-1-5#l1330
[3] 
http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=blob;f=ltmain.in;h=48facb91640a8fd43ad0e7ce4139ec0ccb4bfa09;hb=branch-1-5#l1880


Any idea what could happen here?



To see what's going on I've already added this a few lines before:
        truss -f -o ${libobj}.truss.out -p $$ &
        sleep 1

Now I can see (stripped the unimportant):
        open("GetWMCMapW.loT", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE) = 4
        kfcntl(4, 14, 0x00000001)       = 1
        close(4)                = 0
        open("/tmp//sh-thd-1217607265", 
O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE) = 4
        kfcntl(4, F_DUPFD, 0x00000000)      = 5
        kwrite(5, " p i c _ o b j e c t = '".., 32) = 32
        close(5)                = 0
        open("/tmp//sh-thd-1217607265", O_RDONLY|O_LARGEFILE) = 5
        close(4)                = 0
        unlink("/tmp//sh-thd-1217607265")   = 0
        kfcntl(5, 14, 0x00000000)       = 0
        close(5)                = 0
        execve("/usr/bin/cat", 0x200234E8, 0x20026968)  argc: 1
         argv: cat
        kread(0, " p i c _ o b j e c t = '".., 4096) = 32
        kwrite(1, " p i c _ o b j e c t = '".., 32) = 32
        kread(0, " p i c _ o b j e c t = '".., 4096) = 0
        close(1)                = 0
        _exit(0)

So I'm sure the missing commands above _are_ executed.


My speculation:
1) bash opens the here-document twice, first O_WRONLY, second O_RDONLY,
dup2'ing the second handle to stdin before doing exec('cat'), removing
the file immediately after the second open.

2) ksh opens the here-document only once, with O_RDWR, and dup's that
handle to stdin before doing exec('cat'), removing the file immediately
after the open.

Could one think of: when opening the file the second time, the content
of the first write isn't on-disk yet (because the content might fit into
some aix write buffer), or already removed by someone else in the
meantime, or something like that?

For completeness, this are the contents of one good and one broken
file.lo from the same build:

good$ cat DrArc.lo
        # DrArc.lo - a libtool object file
        # Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.493 2008/02/01 
16:58:18)
        #
        # Please DO NOT delete this file!
        # It is necessary for linking the library.
        
        # Name of the PIC object.
        pic_object='.libs/DrArc.o'
        
        # Name of the non-PIC object.
        non_pic_object=none
        
bad$ cat GetWMCMapW.lo
        # GetWMCMapW.lo - a libtool object file
        # Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.493 2008/02/01 
16:58:18)
        #
        # Please DO NOT delete this file!
        # It is necessary for linking the library.
        
        # Name of the PIC object.
        # Name of the non-PIC object.
        non_pic_object=none

Thoughts?

Thanks!

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level





reply via email to

[Prev in Thread] Current Thread [Next in Thread]