Hello users On Sat, Apr 25, 2009 at 2:31 PM, Derek Spadaro <[email protected]> wrote: > 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 >> >
------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
