Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.