sys-kernel/linux-headers-2.6.25 and up changed _LINUX_CAPABILITY_VERSION. As a result, if squid (2 and 3) is compiled against those headers, it will not be usable (although it will compile without complaining). Recompiling squid with sys-kernel/linux-headers-2.6.24 solves the problem. Maybe it's a duplicate of Bug 221971. Reproducible: Always Steps to Reproduce: 1. compile squid with >=sys-kernel/linux-headers-2.6.25 2. start squid Actual Results: /etc/init.d/squid start * Initializing cache directories ... *** glibc detected *** /usr/sbin/squid: free(): invalid next size (fast): 0x088659b0 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7c0f7ff] /lib/libc.so.6(cfree+0x89)[0xb7c114f9] /usr/sbin/squid[0x81244e2] ======= Memory map: ======== ...
after a world rebuild I had the same problem sys-kernel/linux-headers-2.6.25-r3
Did you guys tried to recompile glibc after you installed the new version of linux-headers?
Yes, I tried to recompile glibc after I installed the new version of linux-headers. It doesn't solve the problem. Installing sys-kernel/linux-headers-2.6.24 without recompiling glibc fixed it.
Trying to valgrind or mudflap this issue, I found two upstream bugs: http://www.squid-cache.org/bugs/show_bug.cgi?id=2350 http://www.squid-cache.org/bugs/show_bug.cgi?id=2359 Neither of these solved the issue, though. Both valgrind and mudflap cause squid to start up without this glibc error message. There are some uninitialized writes in valgrind, and mudflap keeps complaining about CurrentDebug for reasons unknown, but I have no clue what all this has to do with the linux headers.
Hmm... I cannot reproduce the bug. Steps I did: - emerge =sys-kernel/linux-headers-2.6.25-r3 - set CFLAGS=-g and FEATURES=nostrip - emerge =squid-2.6.20 - rm -rf /var/cache/squid/* - /etc/init.d/squid start - echo success Probably I would have to re-emerge glibc for reproducing it.
I compiled against both 2.6.24 and 2.6.25-r3, disassembled all object files, and compared the resulting assembly code. The only relevant difference was in src/tools.o and resulted from a different value for _LINUX_CAPABILITY_VERSION. This reminded me of a comment I had read in an upstream post, and in fact, http://www.squid-cache.org/bugs/show_bug.cgi?id=2350#c3 comment 3 mentions an issue with that constant while comment 4 contains a patch to fix it. So with both patches from the attachments of upstream bug 2350 in place, squid compiles and starts cleanly with sys-kernel/linux-headers-2.6.25-r3. Please add these patches to a new revision of the squid ebuild to close this.
(In reply to comment #0) > Maybe it's a duplicate of Bug 221971. Yes, it is the same reason, the value of _LINUX_CAPABILITY_VERSION. If I had read that before, I might perhaps have saved some time. On the other hand, diffing assembly code of whole projects was a new experience, and the upstream report is still useful for the actual fix. And maybe bug 221971 can profit from these findings.
Fixed in squid-2.6.20-r1 and squid-3.0.6-r1. Thanks! P.S. I still cannot reproduce the bug on squid-2.6.20.
