This is the output of the "/usr/lib/sa/sa1 -S DISK 1 1" cron job on my system with everything current from Rawhide. Running the same command with MALLOC_CHECK_=0 makes the crash go away. *** glibc detected *** /usr/lib/sa/sadc: double free or corruption (!prev): 0x08c9ad28 *** ======= Backtrace: ========= /lib/libc.so.6[0x423231] /usr/lib/sa/sadc[0x8049a2f] /usr/lib/sa/sadc[0x804a6fd] /lib/libc.so.6(__libc_start_main+0xe6)[0x3c9a66] /usr/lib/sa/sadc[0x8048ff1] ======= Memory map: ======== 002b5000-002df000 r-xp 00000000 08:01 15663140 /lib/libgcc_s-4.4.0-20090514.so.1 002df000-002e0000 rw-p 00029000 08:01 15663140 /lib/libgcc_s-4.4.0-20090514.so.1 0038f000-003af000 r-xp 00000000 08:01 15665608 /lib/ld-2.10.1.so 003af000-003b0000 r--p 0001f000 08:01 15665608 /lib/ld-2.10.1.so 003b0000-003b1000 rw-p 00020000 08:01 15665608 /lib/ld-2.10.1.so 003b3000-0051e000 r-xp 00000000 08:01 15665619 /lib/libc-2.10.1.so 0051e000-0051f000 ---p 0016b000 08:01 15665619 /lib/libc-2.10.1.so 0051f000-00521000 r--p 0016b000 08:01 15665619 /lib/libc-2.10.1.so 00521000-00522000 rw-p 0016d000 08:01 15665619 /lib/libc-2.10.1.so 00522000-00525000 rw-p 00000000 00:00 0 00a25000-00a26000 r-xp 00000000 00:00 0 [vdso] 08048000-08058000 r-xp 00000000 08:01 9978787 /usr/lib/sa/sadc 08058000-0805a000 rw-p 0000f000 08:01 9978787 /usr/lib/sa/sadc 08c99000-08cba000 rw-p 00000000 00:00 0 [heap] b808d000-b808f000 rw-p 00000000 00:00 0 bfc27000-bfc3c000 rw-p 00000000 00:00 0 [stack]
Please which version of sysstat do you have?
Could you attach here your /proc/stat, /proc/uptime, /proc/partitions, /proc/diskstats, /proc/interrupts, /proc/meminfo and /proc/self/mountstats files?
I found Debian bug #507659 looking very similar: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507659
Crash appears to be gone in rawhide.
It's crashing again. I'm investigating.
Created attachment 350839 [details] patch to fix double free Well, it took me a while of banging my head against the code to figure it out, but I finally did. The code was set up for two different activity structures, net_dev_act and net_edev_act, to share the same device count. The issue arises when a change in the number of devices is detected while working with one of the activity structures. When this occurs, the device count and buffer size for that structure are adjusted. The changed device count bleeds through into the other activity structure, since the two structures share the same device count, but the buffer size for that other structure is *not* updated, and from that point, the program is vulnerable to memory overruns because of the too-small buffer. The attached patch fixes the problem.
FYI, the maintainer of sysstat says, "Congratulations for fixing this annoying bug that I was personally unable to reproduce. Your patch will be included into next sysstat release."
Thanks, fixed in 9.0.4.