Amos Jeffries wrote:
On Tue, 2008-04-01 at 00:08 +1300, Amos Jeffries wrote:
Probably a muckup by me in the code setting the sockaddr_storage
content. Can you get a trace with output of the sas variable fields?
I have abort()ed Squid after a negative connect() return value is
detected. Here is the backtrace and variables:
(gdb) where
#0 0x283530c7 in kill () from /lib/libc.so.5
#1 0x2834812e in raise () from /lib/libc.so.5
#2 0x283bbcef in abort () from /lib/libc.so.5
#3 0x08140c84 in comm_connect_addr (sock=14, [EMAIL PROTECTED])
at comm.cc:1173
#4 0x081403c6 in ConnectStateData::connect (this=0x8c64010) at
comm.cc:1032
#5 0x0813fc08 in commConnectDnsHandle (ia=0x82a3d34, data=0x8c64010)
at comm.cc:846
#6 0x080ef2dc in ipcache_nbgethostbyname (name=0x83cf048 "10.0.0.104",
handler=0x813faa4 <commConnectDnsHandle>, handlerData=0x8c64010)
at ipcache.cc:726
#7 0x0813f8e2 in commConnectStart (fd=14, host=0x83cf048 "10.0.0.104",
port=1344, [EMAIL PROTECTED]) at comm.cc:801
#8 0x081802a4 in ICAPXaction::openConnection (this=0x8c60010)
at ICAP/ICAPXaction.cc:111
#9 0x08185d13 in ICAPOptXact::start (this=0x8c60010) at
ICAP/ICAPOptXact.cc:27
#10 0x08148e84 in AsyncJob::noteStart (this=0x8c60058) at
ICAP/AsyncJob.cc:33
#11 0x0814aaf4 in NullaryMemFunT<AsyncJob>::doDial (this=0x8b5e69c)
at AsyncJobCalls.h:42
#12 0x08149e50 in JobDialer::dial (this=0x8b5e69c, [EMAIL PROTECTED])
at ICAP/AsyncJob.cc:200
#13 0x0814a97c in AsyncCallT<NullaryMemFunT<AsyncJob> >::fire
(this=0x8b5e680)
at AsyncCall.h:127
#14 0x080692ff in AsyncCall::make (this=0x8b5e680) at AsyncCall.cc:34
#15 0x080687f2 in AsyncCallQueue::fireNext (this=0x83dfd10)
at AsyncCallQueue.cc:53
#16 0x08068656 in AsyncCallQueue::fire (this=0x83dfd10) at
AsyncCallQueue.cc:39
#17 0x080a7db2 in EventLoop::dispatchCalls (this=0xbfbfec20)
at EventLoop.cc:154
#18 0x080a7cf2 in EventLoop::runOnce (this=0xbfbfec20) at EventLoop.cc:131
#19 0x080a7b88 in EventLoop::run (this=0xbfbfec20) at EventLoop.cc:95
#20 0x080f2e74 in main (argc=2, argv=0xbfbfecb8) at main.cc:1361
(gdb) up 3
#3 0x08140c84 in comm_connect_addr (sock=14, [EMAIL PROTECTED])
at comm.cc:1173
1173 abort();
(gdb) set print pretty
(gdb) p address
$1 = (const IPAddress &) @0x8c64028: {
m_SocketAddr = {
sin_len = 16 '\020',
sin_family = 2 '\002',
sin_port = 16389,
sin_addr = {
s_addr = 1744830474
},
sin_zero = "\000\000\000\000\000\000\000"
}
}
(gdb) p sas
$2 = {
ss_len = 16 '\020',
ss_family = 2 '\002',
__ss_pad1 = "[EMAIL PROTECTED]",
__ss_align = 0,
__ss_pad2 = '\0' <repeats 111 times>
}
<snip>
Is it safe to undo your r8901 change until this is fixed?
For all non-Linux OS yes it should be safe.
I think I see the problem already though. The sin_len value is wrong for
the address type. I was not altering it in the re-map since its not on
some OS.
I've made a test patch to fix that:
http://treenet.co.nz/projects/squid/patches/alex-20080401.patch
Though I am not sure if the "#if defined(sin_len)" will work properly. Can
you try it with and without those lines please before you roll back the
initial patches?
And indeed the defines will always fail.
I've polished it a bit, and my final version of this is now at:
http://treenet.co.nz/projects/squid/patches/alex-20080401-b.patch
It will need a re-configure for autotools to perform the new OS tests
looking for ss_len and some equivalents.
Amos
--
Please use Squid 2.6STABLE19 or 3.0STABLE3
