On 22/11/2012 12:32 a.m., Frantisek Hanzlik wrote:
Amos Jeffries wrote:
On 20.11.2012 09:33, Frantisek Hanzlik wrote:
Amos Jeffries wrote:
On 12.11.2012 03:25, Frantisek Hanzlik wrote:
With this squid configuration:
...<snip>
And then I found in /var/log/messages these lines
(/var/log/squid/cache.log contained nothing suspicious(*) ):
Nov 19 16:53:40 172 squid[2834]: Squid Parent: (squid-1) process 32702
exited due to signal 6 with status 0
Ouch. That needs to be found and fixed.
Are you able to assist with that by running Squid under a debugger and
getting a backtrace?
(http://wiki.squid-cache.org/SquidFaq/BugReporting#Using_gdb_debugger_on_a_live_proxy_.28with_minimal_downtime.29)
<snip repeats>
... <snip repeats>
Within several hours I have six core dumps:
# LANG=C ls -l
-rw------- 1 squid squid 31424512 Nov 21 06:03 core.15363
-rw------- 1 squid squid 75161600 Nov 21 06:54 core.17776
-rw------- 1 squid squid 19992576 Nov 21 06:54 core.18266
-rw------- 1 squid squid 91512832 Nov 21 07:27 core.18272
-rw------- 1 squid squid 144785408 Nov 21 07:46 core.18579
-rw------- 1 squid squid 361881600 Nov 21 09:14 core.18754
-rw------- 1 squid squid 307638272 Nov 21 11:46 core.19564
Backraces (without core.15363, it was in previous mail) are:
# for i in core.17776 core.18266 core.18272 core.18579 core.18754 core.19564; do echo -e "\n#gdb ./$i :"; gdb -batch -x gdb.commands ./$i; done
<snip duplicate traces>
#gdb ./core.19564 :
[New Thread 19564]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/c4/1c574f31a203492b9389c783adad6ff1989915
[Thread debugging using libthread_db enabled]
Core was generated by `(squid-1) -f /etc/squid/squid.conf'.
Program terminated with signal 6, Aborted.
#0 0x0032b424 in __kernel_vsyscall ()
#0 0x0032b424 in __kernel_vsyscall ()
#1 0x0055f2f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00560d5e in abort () at abort.c:92
#3 0x00557c08 in __assert_fail (assertion=0x83cf443 "false", file=0x83ff936 "Address.cc", line=689, function=0x83ffca0 "void Ip::Address::GetAddrInfo(addrinfo*&, int) const") at assert.c:81
#4 0x082e1b60 in Ip::Address::GetAddrInfo (this=0x177e1f34, dst=@0xbf9db7dc, force=0) at Address.cc:689
#5 0x082da72b in comm_openex (sock_type=1, proto=6, addr=..., flags=1, tos=0 '\000', nfmark=0, note=0x1b023308 "[2a02:598:1::9999]") at comm.cc:525
#6 0x0832fd65 in Comm::ConnOpener::start (this=0xe7fdf08) at ConnOpener.cc:164
#7 0x082d13be in NullaryMemFunT<AsyncJob>::doDial (this=0x1b01e594) at ../../src/base/AsyncJobCalls.h:101
#8 0x082d15d6 in JobDialer<AsyncJob>::dial (this=0x1b01e594, call=...) at ../../src/base/AsyncJobCalls.h:175
#9 0x082d1775 in AsyncCallT<NullaryMemFunT<AsyncJob> >::fire (this=0x1b01e578) at ../../src/base/AsyncCall.h:142
#10 0x082ce34b in AsyncCall::make (this=0x1b01e578) at AsyncCall.cc:36
#11 0x082d196b in AsyncCallQueue::fireNext (this=0x95966f0) at AsyncCallQueue.cc:54
#12 0x082d1ae0 in AsyncCallQueue::fire (this=0x95966f0) at AsyncCallQueue.cc:40
#13 0x0818edc0 in EventLoop::dispatchCalls (this=0xbf9dbbd4) at EventLoop.cc:154
#14 0x0818eff7 in EventLoop::runOnce (this=0xbf9dbbd4) at EventLoop.cc:131
#15 0x0818f0e0 in EventLoop::run (this=0xbf9dbbd4) at EventLoop.cc:95
#16 0x081ff650 in SquidMain (argc=3, argv=0xbf9dbd44) at main.cc:1500
#17 0x0820076f in SquidMainSafe (argc=3, argv=0xbf9dbd44) at main.cc:1215
#18 main (argc=3, argv=0xbf9dbd44) at main.cc:1207
Although core dump image are from 20MB to 362MB size, all backtraces are similar.
Can I, please, do anything further?
Hmm. IPv6 destination address being connected to by an IPv4-only host. Oops.
Squid only fetches A records when IPv6 is disabled which should have
been enough to prevent IPv6 destinations being found. But possibly this
is a DNS resolver packing AAAA results in to an A lookup, or a raw-IP
request from the client. It is possible those might get into the
connection setup list.
Does this patch fix it for you?
http://treenet.co.nz/projects/squid/patches/Hanzlik_crash_s32_mk1.patch
Apply with "patch -p0" on squid 3.2
Amos
