> I will reiterate my point here that the dynamic linker the first user > of mmap in a newly started process, and the first program to read and > process data from the mmap'd files. Therefore the dynamic linker is > always the first to suffer if a mapped region of memory is not > correct. That is true to a certain extent. However, there are large portions of code and initialized data that it doesn't touch. I don't think that I've ever seen an invalid instruction fault. So, I'm not fully convinced that we understand the cause of these segvs. As far as I can tell, the mmap'd data appears correct (at least as far as what was recorded in the core file). What is wrong is the l_info field in the linker map. Prior to failing on processing libdl.so.2, it had successfully processed itself and libncurses.so.5 (see NEEDED entries for /bin/sh). There isn't a lot that happens between mmap'ing the file and the access to the STRTAB entry in the l_info field. The NEEDED entry at l_info[1] seems ok in the dump. I doubt this is a TLB issue as the data is a long way from page boundaries. Possibly, there is a cache line issue in the mmap'd file, or as I suggested before a race condition and the file isn't fully mapped when the mmap call returns. In any case, the extraction of the dynamic data failed after doing the first NEEDED entry. I have to think that this has something to do with the machine being a rp3440 (large memory and cache). I have never seen this on my c3750 with 32-bit UP kernel. Also, this was with a 64-bit UP kernel. > What we need to do here is create a test case. > > I tried this: > > 1. cp /lib/libc.so.6 original.so > 2. cp /lib/libc.so.6 map.so > 3. gcc -O2 -g -o test-mmap test-mmap.c > 4. while true; do ./test-mmap ./original.so ./map.so; done; > > The test mmap's a file and compares it to the original, aborting if > the comparison fails. I've yet to see it abort on my a500, and I've > run 20-30 instances of the test simultaneously. Then again I don't see > any serious segv's like others do (2.6.26-1-parisc64-smp). > > What might be a better testcase? I typically run my GCC builds with `make -j 4'. So, there's a mix of other stuff actively running at any time. I'll give the testcase a try tonight. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html