pybootchartgui crashed with ZeroDivisionError in draw_chart()

I have a fix in lp:~jderose/ubuntu/karmic/pybootchartgui/fix-441660 and proposed a merge into lp:ubuntu/pybootchartgui

If you upload the datafile /var/log/bootchart/username-desktop-karmic-20091003-2.tgz then I'll have a look too.

Best
Anders (upstream)

I attached the most recent bootchart data I was testing on, but I've personally encountered this bug consistently for about the last month during I've been testing Karmic in a VM.

I also revised my fix, please see revno 5 in lp:~jderose/ubuntu/karmic/pybootchartgui/fix-441660 (it now shows up in the merge proposal).

Hi Jason,

It looks like the disk use and disk throughput is all zeroes. I wonder if the parsing code in pybootchartgui is broken or if somehow the dumping of diskusage data is broken when running in QEMU.

I'll look a bit more and run bootchart in some VM's.

Otherwise maybe just doing

 yscale = float(chart_bounds[3]) / max(0.00001, max(y for (x,y) in data))

would also do? (at least as a workaround)

Best
Anders

Hi again,

The parsing was wrong - missing the virtual disks. This should now be fixed in r139

http://code.google.com/p/pybootchartgui/source/detail?r=139

"Make sure parsing also matches virtual disks, conventionally called vda, vdb
etc. - should fix https://bugs.launchpad.net/bugs/441660"

Best
Anders

Anders,

Thanks for looking at this and thanks for the fix! I should have looked closer at the bootchart data. ;)

Yeah, the Linux virtio para-virtual block devices are /dev/vd{a,b,c,...}

Cheers,
Jason

One other thought: some kind of fix for potential division-by-zero errors should probably still be added. I didn't look closely at the meaning of the data, but if very short time intervals have the potential to be zero (depending on the time granularity available), this could still be a problem on a VM.

Many hosts will have enough RAM to cache all areas of the guest disk used during boot, so subsequent boots of the VM will be entirely from memory... so it seems feasible to have zero-time events.

Hmm, since the divisor is the maximum of the timeseries of {CPU-use, I/O wait, disk-throughput, disk utilization}, and neither of those series should be all zeroes, I don't think there is any possibility of divide-by-zero for properly parsed data.

Ubuntu updated to -r139