libvirtd assert failure: *** glibc detected *** /usr/sbin/libvirtd: realloc(): invalid next size: 0x00007f289004d5e0 ***

StacktraceTop:
 raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 abort () at abort.c:92
 __libc_message (do_abort=2, fmt=0x7f28998945d0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
 malloc_printerr (action=3, str=0x7f28998918e7 "realloc(): invalid next size", ptr=<value optimized out>) at malloc.c:6283
 _int_realloc (av=0x7f2890000020, oldp=0x7f289004d5d0, oldsize=<value optimized out>, nb=96816) at malloc.c:5238

Thanks for reporting this bug and helping to make Ubuntu better.

Does this still happen? Do you have any VM's set to autostart with libvirt?

I do have some virt manager VMs set up, but none of them set up to autostart.

So far I've only seen this pop up once.

er, "pop up once recently."

It seems to happen very intermittently, maybe once every 10 boots or more.

Thanks, Roland. When it happens next could you attach a new stack trace? (perhaps just 'apport-collect 726099' will upload the info). The stacktrace attached so far suggests that libc's malloc is at fault, so we may want to mark this bug as affecting libc as well. But I'd like to see if another stacktrace is identical, or randomly different.

Sure, will do.

To be honest, the first time around happened long enough ago that I didn't even realize that the second crash was a duplicate...

Two of the duplicates are from lucid, have the same eglibc signature as this one (bad old size in realloc), but those don't show where that was called. This bug (the original) and the other dup from natty both show libpcialloc to be the one which called realloc when it failed.

Hi,

could everyone please install the amd64 packages in comment #11 and shout if it happens again with these packages?

many thanks.

I'm not 64bit, I'm pae.

Please collect a full backtrace - see http://wiki.ubuntu.com/X/Backtracing for directions.

Or, if the libvirt fix solves it sufficiently, and no action is needed for libpciaccess you can close out the libpciaccess task.

Can anyone who has installed the proposed packages please comment to let us know how long they've been using it? We'd like an idea of wether (a) noone is using it or (b) people using it are just not seeing the issue any more.

many thanks.

I only saw it once.

closing for libpciaccess

This is no more a supported version now