[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Troubles analyzing crash dumps from xl dump-core


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Roman Shaposhnik <roman@xxxxxxxxxx>
  • Date: Fri, 29 Jan 2021 12:12:00 -0800
  • Delivery-date: Fri, 29 Jan 2021 20:12:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi!

I'm trying to see how much mileage I can get out of
crash(1) 7.2.8 (based on gdb 7.6) when it comes to
analyzing crash dumps taken via xl dump-core (this
is all on x86_64 with stock Xen v. 4.14).

The good news is that the image actually does load
up but it throws the following WARNINGs in the process:

WARNING: cannot access vmalloc'd module memory
crash: read error: kernel virtual address: ffffffff93613480  type:
"fill_task_struct"
WARNING: active task ffffffff93613480 on cpu 0 not found in PID hash
crash: read error: kernel virtual address: ffffffff93613480  type:
"fill_task_struct"
WARNING: cannot read log_buf contents

And then the info that it gives me around basic things like
ps, mod, log, etc. is really super limited (and I am now suspecting
may even be wrong).

Since I was primarily after dmesg/log initially, I tried:
crash> log
log: WARNING: cannot read log_buf contents

Then I tried taking an xl dump-core from the domU that was still
very much alive and happy and got similar results -- so it clearly
doesn't seem to be related to the state domU is in.

As matter of fact, I actually got to the desired dmesg output
by simply running strings(1) on the core file -- so the info is
definitely there -- but I guess some kind of index/reference maybe
broken.

With all that in mind, if there's anyone on this ML who has recently
done Xen DomU crash dump analysis -- I would definitely appreciate
the pointers!

Thanks,
Roman.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.