Another 1.1.14 segmentation fault found

From: Michael Pelletier <>
Date: Tue, 29 Jul 1997 13:27:04 -0400 (EDT)

After fixing the previous segmentation fault by a quick null check, I ran
into this segmentation fault:

(gdb) run -f /usr/local/squid/etc/squid-test.conf
Starting program: /usr/local/squid/bin/./squid-1.1.14+retry+segfix -f

Program received signal SIGSEGV, Segmentation fault.
httpReadReplyTimeout (fd=26, data=0x0) at http.c:249
(gdb) where
#0 httpReadReplyTimeout (fd=26, data=0x0) at http.c:249
#1 0xaf7c in checkTimeouts () at comm.c:1508
#2 0xa0ec in comm_select (sec=1) at comm.c:1105
#3 0x1edf6 in main (argc=3, argv=0xefbfda78) at main.c:702

   244 static void
   245 httpReadReplyTimeout(int fd, void *data)
   246 {
   247 HttpStateData *httpState = data;
   248 StoreEntry *entry = NULL;
-> 249 entry = httpState->entry; <---------
   250 debug(11, 4, "httpReadReplyTimeout: FD %d: '%s'\n",fd,entry->url);
   251 squid_error_entry(entry, ERR_READ_TIMEOUT, NULL);
   252 commSetSelect(fd, COMM_SELECT_READ, NULL, NULL, 0);
   253 comm_close(fd);
   254 }

I'm still trying to figure out where the httpReadReplyTimeout() handler
was set, and why it got a null httpState value. It almost looks as if it
might have been deallocated or nulled out later, because the two functions
where this particular handler is set (httpSendComplete() and
httpReadReply()) have lines in them that would have caused segmentation
faults if httpState had been NULL before the commSetSelect().

Here's the last reference in the logfile to FD 26:
97/07/29 11:57:53| protoCancelTimeout: FD 26
97/07/29 11:58:12| protoDispatch: inside_firewall = 2 (NO_FIREWALL)
97/07/29 11:58:12| protoDispatch: hierarchical = 0
97/07/29 11:58:12| protoDispatch: n_peers = 0
97/07/29 11:58:12| protoDispatch: single_parent = N/A
97/07/29 11:58:12| protoDispatch: default_parent = N/A

And again, this crash only happened as a result of 15-20 minutes of steady
web browsing by only me, through a v1.1.14 Squid with my connection-retry
patch applied -- that part appears to be working fine, unless its dinking
with shortening the fd lifetime using comm_set_fd_lifetime() is somehow
part of this problem. But then, has only one IP
address, and so would get the normal 120 second timeout...

This is probably related to the original segmentation fault, and the real
root problem is handler data getting set to "NULL".

Any suggestions?

        -Mike Pelletier.
Received on Tue Jul 29 1997 - 10:35:52 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:35:52 MST