oops.. sent too soon. Original: Hello users I was asking around a few weeks back about aufs using uClibc. I am still wrestling with this issue. GDB tells me that when this fault occurs uClibc __start is passed a pointer to the application's main which is bogus. It seems to happen during the fix-ups after loading shared libraries: if I stop it before these are loaded all is well. In any case I wonder if this might be resolved with a newer version of squashfs. The current squashfs version is 3.2 because the kernel version is 2.6.21. Does anyone know of a success story with 3.3 or 3.4 with such an old kernel, or is this a pointless exercise? Thanks Derek
On Wed, May 13, 2009 at 8:05 PM, Derek Spadaro <[email protected]> wrote: > 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
