----- Original Message -----
----- Original Message -----
> > > $ git diff memory.c
> > > diff --git a/memory.c b/memory.c
> > > index 8cdab06..7161d9d 100644
> > > --- a/memory.c
> > > +++ b/memory.c
> > > @@ -8722,6 +8722,11 @@ dump_vmap_area(struct meminfo *vi)
> > > ld->list_head_offset = OFFSET(vmap_area_list);
> > > ld->end = symbol_value("vmap_area_list");
> > > cnt = do_list(ld);
> > > + if (cnt < 0) {
> > > + vi->retval = 0;
> > > + FREEBUF(vmap_area_buf);
> > > + return;
> > > + }
> > >
> > > for (i = 0; i < cnt; i++) {
> > > if (!(pc->curcmd_flags & HEADER_PRINTED) &&
(i ==
> > > 0) &&
> > >
> > > --
> >
> > I was wondering how the search command would handle its call to
machdep->get_kvaddr_ranges()
> > with the patch above -- which would return 0 as the vmalloc address range's
"end" address.
> > But given your output above, apparently it seems to work around it.
> >
> > Thanks,
> > Dave
> >
> >
>
> As far as I could tell, the code properly checks for a non-zero
> meminfo.retval before proceeding in all instances.
OK -- so I'll take your patch, but also add an additional vmap_area list
specific message to your patch so that the invalid list entry message
is not so cryptic as to what it's complaining about.
Thanks,
Dave
Hi Dave,
The patch is queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/2500d9627526caf5c496df77fff...
Dave