----- Original Message ----- > On Wed, May 9, 2012 at 3:57 PM, Dave Anderson <anderson@xxxxxxxxxx> > wrote: > > > > > > ----- Original Message ----- > >> >> First, just like some other contributors, I've come across an > >> >> issue > >> >> triggered by a dump being corrupt. In my case it's this code in > >> >> kernel.c:cpu_maps_init(): > >> >> > >> >> if (*maskptr & (0x1UL << c)) { > >> >> cpu = (i * BITS_PER_LONG) + c; > >> >> kt->cpu_flags[cpu] |= mapinfo[m].cpu_flag; > >> >> } > >> >> > >> >> The mask is corrupt, making Crash believe there are more CPU's > >> >> than the > >> >> four we have allocated space for in kernel.c:kernel_init. How > >> >> do you > >> >> think this should be handled? > >> > > >> > Does the "crash --cpus <number> ..." command-line option work > >> > around it? > >> > > >> > >> Nope, setting "--cpus 2" I still arrive at the code above with > >> > >> (gdb) p/x *maskptr > >> $3 = 0x540dcebf > >> (gdb) > >> > >> As you can see, it's not really a valid cpu mask. Either that or I'm > >> totally deluded as to the capabilities of the hardware CPU-wise =o) > > > > Right, I understand that cpu_maps_init() will still be called, and that > > kt->cpu_flags will be invalid. But then what happens? > > > > Well, it will fill in flags for imagined cpus up to #30, since that's > the highest bit set in the mask, using those cpu numbers to index into > a four element large array allocated on the heap, potentially > overwriting stuff it shouldn't. For me, I never actually got any > symptoms from it - I just came across it through valgrind while > investigating the trace extension problem I reported. > > /Per So then the code should just recognize that the "cpu" value is beyond the architecture's maximum array index, report the inconsistency, and "continue" on to the next map? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility