You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Pane <br...@cnet.com> on 2001/11/21 19:55:32 UTC
segv in socket read
I'm seeing this randomly on Solaris, with a build compiled from
the latest CVS head about 5 minutes ago:
gdb) where
#0 0xff34fab8 in apr_wait_for_io_or_timeout (sock=0xe3130, for_read=1)
at sendrecv.c:70
#1 0xff34fd4c in apr_recv (sock=0xe3130, buf=0x103270 "", len=0xfdf03778)
at sendrecv.c:142
#2 0xff38459c in socket_read (a=0xb9888, str=0xfdf0377c, len=0xfdf03778,
block=APR_BLOCK_READ) at apr_buckets_socket.c:75
#3 0x49b08 in core_input_filter (f=0x0, b=0xe78f0, mode=AP_MODE_BLOCKING,
readbytes=0xfdf0394c) at core.c:2964
#4 0x41fd0 in ap_get_brigade (next=0x0, bb=0xe78f0, mode=AP_MODE_BLOCKING,
readbytes=0xfdf0394c) at util_filter.c:250
#5 0x495cc in net_time_filter (f=0xe7920, b=0xe78f0, mode=AP_MODE_BLOCKING,
readbytes=0xfdf0394c) at core.c:2809
#6 0x41fd0 in ap_get_brigade (next=0xe7920, bb=0xe78f0,
mode=AP_MODE_BLOCKING,
readbytes=0xfdf0394c) at util_filter.c:250
#7 0x431fc in ap_getline (s=0xfdf039d0 "", n=8192, r=0xe7160, fold=0)
at protocol.c:224
#8 0x43570 in read_request_line (r=0xe7160) at protocol.c:412
#9 0x43ac4 in ap_read_request (conn=0xef1d0) at protocol.c:583
#10 0x26ea0 in ap_process_http_connection (c=0xef1d0) at http_core.c:296
#11 0x40558 in ap_run_process_connection (c=0xef1d0) at connection.c:84
#12 0x40890 in ap_process_connection (c=0xef1d0) at connection.c:229
#13 0x32900 in process_socket (p=0xef1d0, sock=0xe3130, my_child_num=1,
my_thread_num=1) at worker.c:502
#14 0x32f14 in worker_thread (thd=0xd72a8, dummy=0x724f8) at worker.c:715
#15 0xff352c20 in dummy_worker (opaque=0xd72a8) at thread.c:122
The line corresponding to the segv is doing this:
FD_SET(sock->socketdes, &fdset);
and it's crashing because sock->socketdes==-1
(gdb) p *sock
$3 = {cntxt = 0xe3100, socketdes = -1, type = 2, local_addr = 0xe3160,
remote_addr = 0xe3198, timeout = 300000000, local_port_unknown = 0,
local_interface_unknown = 0, netmask = 544, inherit = 0}
--Brian
install didn't respect manualdir
Posted by Gomez Henri <hg...@slib.fr>.
I saw a little problem in Makefile.in which didn't install
correctly manual dir, it use prefix/manual instead of manualdir :
Here is the fix :
--- Makefile.in.orig Thu Nov 22 00:36:09 2001
+++ Makefile.in Thu Nov 22 00:37:01 2001
@@ -95,8 +95,8 @@
@echo Installing HTML documents
@test -d $(htdocsdir) || $(MKINSTALLDIRS) $(htdocsdir)
@test -d $(htdocs-srcdir) && (cd $(htdocs-srcdir) && cp -rp * $(htdocsdir))
-
@test -d $(prefix)/manual || $(MKINSTALLDIRS) $(prefix)/manual
-
@test -d $(top_srcdir)/docs/manual && (cd $(top_srcdir)/docs/manual && cp -rp *
$(prefix)/manual)
+
@test -d $(manualdir) || $(MKINSTALLDIRS) $(manualdir)
+
@test -d $(top_srcdir)/docs/manual && (cd $(top_srcdir)/docs/manual && cp -rp *
$(manualdir))
@(cd $(htdocsdir) && find . -name "CVS" -print | xargs rm -rf {} \;)
Regards
-
Henri Gomez ___[_]____
EMAIL : hgomez@slib.fr (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: segv in socket read
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 21 November 2001 11:14 am, Jeff Trawick wrote:
> Brian Pane <br...@cnet.com> writes:
> > I'm seeing this randomly on Solaris, with a build compiled from
> > the latest CVS head about 5 minutes ago:
> >
> > gdb) where
> > #0 0xff34fab8 in apr_wait_for_io_or_timeout (sock=0xe3130, for_read=1)
> > at sendrecv.c:70
>
> set a breakpoint in the apr socket cleanup routine and see who closed
> your socket before you got here
>
> > #1 0xff34fd4c in apr_recv (sock=0xe3130, buf=0x103270 "",
> > len=0xfdf03778) at sendrecv.c:142
> > #2 0xff38459c in socket_read (a=0xb9888, str=0xfdf0377c, len=0xfdf03778,
> > block=APR_BLOCK_READ) at apr_buckets_socket.c:75
> > #3 0x49b08 in core_input_filter (f=0x0, b=0xe78f0,
> > mode=AP_MODE_BLOCKING, readbytes=0xfdf0394c) at core.c:2964
>
> bad first param to core_input_filter() above
>
> > #4 0x41fd0 in ap_get_brigade (next=0x0, bb=0xe78f0,
> > mode=AP_MODE_BLOCKING, readbytes=0xfdf0394c) at util_filter.c:250
>
> bad first param to ap_get_brigade() above
This has to be a corrupted stack. If the next pointer is NULL, then we couldn't
have called the next filter in the chain.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: segv in socket read
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <br...@cnet.com> writes:
> I'm seeing this randomly on Solaris, with a build compiled from
> the latest CVS head about 5 minutes ago:
>
> gdb) where
> #0 0xff34fab8 in apr_wait_for_io_or_timeout (sock=0xe3130, for_read=1)
> at sendrecv.c:70
set a breakpoint in the apr socket cleanup routine and see who closed
your socket before you got here
> #1 0xff34fd4c in apr_recv (sock=0xe3130, buf=0x103270 "", len=0xfdf03778)
> at sendrecv.c:142
> #2 0xff38459c in socket_read (a=0xb9888, str=0xfdf0377c, len=0xfdf03778,
> block=APR_BLOCK_READ) at apr_buckets_socket.c:75
> #3 0x49b08 in core_input_filter (f=0x0, b=0xe78f0, mode=AP_MODE_BLOCKING,
> readbytes=0xfdf0394c) at core.c:2964
bad first param to core_input_filter() above
> #4 0x41fd0 in ap_get_brigade (next=0x0, bb=0xe78f0, mode=AP_MODE_BLOCKING,
> readbytes=0xfdf0394c) at util_filter.c:250
bad first param to ap_get_brigade() above
> #5 0x495cc in net_time_filter (f=0xe7920, b=0xe78f0, mode=AP_MODE_BLOCKING,
> readbytes=0xfdf0394c) at core.c:2809
> #6 0x41fd0 in ap_get_brigade (next=0xe7920, bb=0xe78f0,
> mode=AP_MODE_BLOCKING,
> readbytes=0xfdf0394c) at util_filter.c:250
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...