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>
}
(gdb) p x
$3 = -1
(gdb) p errno
$4 = 22
(gdb) p slen
$5 = 128
(gdb) p sock
$6 = 14
(gdb) p *F
$7 = {
  type = 3,
  remote_port = 0,
  local_addr = {
    m_SocketAddr = {
      sin_len = 0 '\0',
      sin_family = 0 '\0',
      sin_port = 0,
      sin_addr = {
        s_addr = 0
      },
      sin_zero = "\000\000\000\000\000\000\000"
    }
  },
  tos = 0 '\0',
  sock_family = 2,
  ipaddr = '\0' <repeats 74 times>,
  desc = "icap://10.0.0.104:1344/request", '\0' <repeats 33 times>,
  flags = {
    open = 1,
    close_request = 0,
    write_daemon = 0,
    closing = 0,
    socket_eof = 0,
    nolinger = 0,
    nonblocking = 1,
    ipc = 0,
    called_connect = 1,
    nodelay = 1,
    close_on_exec = 1,
    read_pending = 0,
    write_pending = 0
  },
  bytes_read = 0,
  bytes_written = 0,
  pconn = {
    uses = 0,
    pool = 0x0
  },
  epoll_state = 0,
  disk = {
    wrt_handle = 0,
    wrt_handle_data = 0x0,
    write_q = 0x0,
    write_q_tail = 0x0,
    offset = 0
  },
  read_handler = 0,
  read_data = 0x0,
  write_handler = 0,
  write_data = 0x0,
  timeoutHandler = {
    p_ = 0x8b60600
  },
  timeout = 1206973014,
  lifetime_data = 0x0,
  closeHandler = {
    p_ = 0x8b5e7c0
  },
  wstate = 0x0,
  read_method = 0x80acaa4 <default_read_method(int, char*, int)>,
  write_method = 0x80acac8 <default_write_method(int, char const*, int)>
}

Is it safe to undo your r8901 change until this is fixed?

Thank you,

Alex.
Received on Mon Mar 31 2008 - 08:22:44 MDT