Michael, The fix is queued for crash-7.1.3: https://github.com/crash-utility/crash/commit/8119552763dfe790b7d4062b26a36bfd6d280a6a Thanks for catching this, Dave ----- Original Message ----- > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > On Tue, 4 Aug 2015 16:57:35 -0400 (EDT) > > > Dave Anderson <anderson@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > Michael > > > > > > > > > > OK, so it would seem to be somewhere in the trail from enumerator_value() > > > > > into the gdb_command_funnel() via the GNU_GET_DATATYPE req->command in > > > > > datatype_info(). > > > > > > > > > > I'm having a hard time provisioning an s390x machine internally at this time. > > > > > When I get one, I'll see if the problem has been there all along. > > > > > > > > > > Dave > > > > > > > > > > > > > Michael, > > > > > > > > I finally got access to an s390x and I see the same thing. In fact it also > > > > happens on a RHEL6 2.6.32-based kernel, so it appears it's always been an > > > > issue. I'll look into it tomorrow. > > > > > > Great, thanks! > > > > > > Michael > > > > > > > The problem is in gdb-7.6/gdb/symtab.c, in the eval_enum() function that > > gets created/added by the crash utility's gdb-7.6.patch: > > > > static void > > eval_enum(struct type *type, struct gnu_request *req) > > { > > register int i; > > int len; > > int lastval; > > > > len = TYPE_NFIELDS (type); > > lastval = 0; > > > > for (i = 0; i < len; i++) { > > if (lastval != TYPE_FIELD_BITPOS (type, i)) { > > lastval = TYPE_FIELD_BITPOS (type, i); > > } > > if (STREQ(TYPE_FIELD_NAME(type, i), req->name)) { > > req->tagname = "(unknown)"; > > req->value = lastval; > > return; > > } > > lastval++; > > } > > } > > > > The function is only used for anonymous (nameless) enums like MM_ANONPAGES. > > It simply walks through the enumerator fields and looks for a matching string, > > having captured the value of each enumerator in "lastval". This function hasn't > > changed, and has simply been forward-ported with each upgrade of gdb. What has > > changed, though, is gdb itself between gdb-7.3.1 and gdb-7.6, which added a new > > TYPE_FIELD_ENUMVAL() macro, which should replace the two instances of > > TYPE_FIELD_BITPOS() above. > > > > I'm thinking that this is an endian issue, where the generic TYPE_FIELD_BITPOS() > > macro works OK for little-endian machines, and probably has always failed for big-endian > > machines. I'm provisioning a big-endian ppc64 to verify that. (Although I'm not sure > > what macro should have been used in the older gdb versions that didn't have > > a TYPE_FIELD_ENUMVAL()?) > > > > Anyway, that's the resolution -- I'll be updating the gdb-7.6.patch > > upstream later today > > or tomorrow. > > > > Dave > > FYI, this is an endian issue. Fortunately very few anonymous enums are utilized by > the crash utility: > > MM_ANONPAGES/MM_FILEPAGES (2.6.34 and later) > ZONE_ALL_UNRECLAIMABLE (pre-2.6.34) > WORK_CPU_UNBOUND (2.6.36 and later) > > The ZONE_ALL_UNRECLAIMABLE enum value is 0, so that works OK by mistake. The WORK_CPU_UNBOUND > enum is used for kt->kernel_NR_CPUS, but if it gets set to 0 by mistake, all users of it in > the crash utility will utilize the per-arch NR_CPUS value compiled into the crash utility, > so it's a benign problem. > > So what this boils down to is a faulty "ps" RSS value when analyzing 2.6.34 and later big-endian > kernels. > > Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
