Re: comm_connect_addr broke in squid3/trunk?

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, 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?
>

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