> On Tue, Jul 7, 2009 at 6:07 PM, John David > Anglin<dave@xxxxxxxxxxxxxxxxxx> wrote: > > I would guess that the loop terminated early because the l_info array > > is all zeros except for the first NEEDED entry. =A0It appears correct. = > =A0The > > loop might have terminated early because of a cache issue, or possibly > > the value loaded from memory somehow got corrupted. =A0Another possibilit= > y > > would be the mmap operation wasn't complete when the memory was examined > > by the dynamic loader. =A0When the core dump was done, the operation was > > complete. > > > > I think it's less likely that a cache issue affected the memory used by > > the dynamic loader (l_info field) as the data before and after in the > > map seemed reasonable. > > > > The fact PA8700 processors are also experiencing similar problems > > would seem to suggest that this isn't a PA8800 L2 issue unless we have > > multiple problems. > > > > I think we need to try running a recent kernel on gsyprf11 for a while > > to see if we can capture a similar event. > > This rang a bell... > > In glibc/elf/rtld.c we have this: > > /* Partly clean the `bootstrap_map' structure up. Don't use > `memset' since it might not be built in or inlined and we cannot > make function calls at this point. Use '__builtin_memset' if we > know it is available. We do not have to clear the memory if we > do not have to use the temporary bootstrap_map. Global variables > are initialized to zero by default. */ > #ifndef DONT_USE_BOOTSTRAP_MAP > # ifdef HAVE_BUILTIN_MEMSET > __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_inf= > o)); > # else > for (size_t cnt =3D 0; > cnt < sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_info[0= > ]); > ++cnt) > bootstrap_map.l_info[cnt] =3D 0; > # endif > > On hppa we don't have builtin memset (probably one of the few arches), > so we fall back on this weird loop which I always thought was wrong. > > I was seeing problems with l_info having garbage in it, so I had a > local hack which cleared the entire bootstrap_map. > > Did your l_info come from the bootstrap_map? No. The l_info fields for the dynamic loader and libncurses.so.5 had already been processed. The segv occurred processing the needed entry for libdl.so.2. The code was processing the needed entries for /bin/sh. The cause of the corruption that you observed is not obvious to me. 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
