The easiest way I have reproduced this problem is that /bin/busybox seg faults the first time running it from a newly mounted aufs root. It is using gcc 4.2.3 and uClibc 0.30.0, built with buildroot (buildroot.uclibc.org). It never happens when the file exists first in the r/w branch, only after first copy-up from r/o branch. At this point I am assuming it has something to do with uClibc and aufs interactions. I need to find a suitable glibc to re-build without uClibc. That is a non-trivial effort which I will keep trying to work on. Also I will get gdb on it and hopefully learn more.
In terms of reproduction you may want to wait since it is also possible to be a uClibc issue rather than aufs, and quite frankly working with uClibc, even with buildroot, can be a bit of a pain if you have not before. I appreciate the help though. Derek On Wed, Apr 22, 2009 at 10:11 PM, <[email protected]> wrote: > > Derek Spadaro: >> Thank you for the patch suggestion, but it did not change the >> behaviour in this case. Now also I am less sure about the >> relationship to shared libraries, as this would not explain why simply >> touching the executable helps. Touch doesn't run the program, nor >> does it load any of the program's shared libraries, so I am not sure >> what it is doing to fix it; or what it is fixing, for that matter. > > touch(1) causes internal file copy-up, and it is related to aufs > mmap(2). > In mmap(2), which branch the file exists is important to aufs and the > previous patch changes its behaviour. > Currently I am guessing your problem is related to copy-up. The first > execution might occur copyup (and aborted). In the second time, no > copyup occured since the file was already copied-up. > touch(1) before execution surely makes file copied-up, and next > execution succeeded. > > I am afraid that I have to read source files in userspace, since all > systemcalls in your strace log succeeded and the segv happend in > userspace. > I am new to uClibc and know nothing about /usr/occam/bin/pdcpshim > either. How can I get source files of them (the exact version which you > are using) to reproduce the problem? > > By the way, if you stop using uClibc and replace it by glibc, can you > reporduce the problem? > > > J. R. Okajima > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
