Re: comm_connect_addr broke in squid3/trunk?

>
> 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, address=@0x8c64028)
> 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, cb=@0x8c60048) 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, call=@0x8b5e680)
> 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, address=@0x8c64028)
> 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 = "\005@\n\000\000h",
> __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?

Amos
Received on Mon Mar 31 2008 - 19:19:25 MDT