I have a serious problem on tree of my systems. glibc detects "double free or corruption": *** glibc detected *** *: double free or corruption {...} This does only happen with a few applications and not in every situation. Unfortunately I can reproduce this on ppc64, amd64 and x86 (this is a amd64 machine running x86). I'll attach outputs and 'emerge --info' of the ppc64 and amd64 machine. I'm currently downgrading to gcc-4.1.1-r1 as I've updated to that version in the timeframe the corruption appeared.
Created attachment 109617 [details] ppc64_emerge_info.txt
Created attachment 109618 [details] vlc_double_free_ppc64.txt
Created attachment 109620 [details] amd64_emerge_info.txt
Created attachment 109622 [details] dspam_double_free_amd64.txt now this a really mysterious situation: if I change "--user tsr" to "--user markus" the programm does not crash. Unfortunately I've deleted the file triggering this, so I can no longer reproduce... :-/
please note that I've updated glibc on the amd64 system to check if a newer one would fix the problem. So you see glibc-2.5 in "emerge --info", but ld-2.4.so in the output.
this seems not to be releated to gcc-4.1.1-r3 as downgrading to gcc-4.1.1-r1 did not fix the problem.
"double free or corruption (out)" means that free() detected that it was about to free a chunk from a contiguous set of chunks, but the chunk was outside the range of the set. What this usually means is that the application is free()'ing memory that it has already free()'ed, or that it is free()'ing a block that wasn't malloc()'ed earlier. It _could_ mean there's a bug in glibc - but that's less likely. IOW the first assumption has to be that these are application bugs (rather than glibc). Report them upstream; if they can reproduce the bug then they're in a much better position to figure it out and fix it :) In the first instance I suggest reporting the x86 variants.
yes, sound like a plan :-) after some testing here and there I can not figure out if the above two examples are connected in any way... I'll close this as INVALID and report this upstream when I have some real data.
closing
