Jeff Trawick wrote:
>
> The script below will force a core dump.
We now know that this can be shortened to the last 2 GETs. I also found
out that every core dump involving apr_dir_close is a GET to a subdir of
/www.apache.org/mail/ .
>
> socket
> connect LASTFD www.apache.org 80
> #
> write LASTFD "GET /mail/apache-docs/?N=D HTTP/1.0\r\nAccept: */*\r\nReferer:
>http://www.apache.org/mail/apache-docs/\r\nPragma: no-cache\r\nUser-Agent:
>Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)\r\nHost:
>www.apache.org\r\nConnection: Keep-Alive\r\n\r\n"
> #
> write LASTFD "GET /mail/apache-docs/?M=A HTTP/1.0\r\nAccept: */*\r\nReferer:
>http://www.apache.org/mail/apache-docs/\r\nPragma: no-cache\r\nUser-Agent:
>Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)\r\nHost:
>www.apache.org\r\nConnection: Keep-Alive\r\n\r\n"
>
I also found out that AP_DEBUG_ASSERT()s which look for a bad dirstruct
throughout index_directory() don't pop. In fact, when I put an assert()
in apr/file_io/unix/dir.c right before the closedir() call to check for
a bad dirstruct->dd_fd value, it is very happy also. Then the
closedir() fails and the assert() after the closedir() pops, and
dirstruct in the core dump looks like trash (dd_fd is zero, for one
thing).
I captured a truss of this problem. It is on daedalus in
/usr/local/apache2b/index_closedir.trace . truss.core in the same
directory is probably a matching core dump. In the tail end of the
trace, you can see:
gettimeofday(0xbfbfa484,0x0) = 0 (0x0)
write(2,0xbfbfa530,209) ERR#9 'Bad file
descriptor'
close(2) ERR#9 'Bad file
descriptor'
close(2) ERR#9 'Bad file
descriptor'
getdirentries(0x2,0x81cf000,0x1000,0x80af154) ERR#9 'Bad file
descriptor'
close(2) ERR#9 'Bad file
descriptor'
fstat(2,0xbfbfd340) ERR#9 'Bad file
descriptor'
write(2,0x81cf000,44) ERR#9 'Bad file
descriptor'
The gettimeofday, write(2,blah), close(2), close(2) sequence happens
repeatedly throughout this trace, but the getdirentries(0x2,blah)
failure seems to be the first sign of real trouble.
Greg
