On Wednesday 21 November 2001 11:14 am, Jeff Trawick wrote: > Brian Pane <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
