On Wed, May 13, 2009 at 9:38 PM, <[email protected]> wrote: > > Derek Spadaro: >> 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? > > Squashfs? > Do you mean squashfs is the root cause of your problem? I thought aufs > copyup is related.
I don't know. I am guessing squashfs could also be root cause as this only occurs before first aufs copy-up from R/O (squashfs) branch. If the executable exists already in R/W branch there is no problem. As I know, squash uses its own caches for file extracting (about which I know very little) so I wonder if it could be related. > > If you give me your reproducible environment or tell me how to construct > it, I will test it. I am still working on it. Reproduction is difficult because the application is an embedded system using MIPS processor. I may need to try 2.6.21.5 kernel, 0.9.30 uClibc, and 3.2 squashfs on a desktop. But this environment is not created very easily. Also I have still failed thus far to compile glibc for MIPS. > > > 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
