looks like the child was taking a while to go away and the parent
interrupted whatever it was doing with SIGTERM
#0 apr_allocator_free (allocator=0x8098900, node=0x8147000) at apr_pools.c:352
352 next = node-next;
(gdb) where
#0 apr_allocator_free (allocator=0x8098900,
Jeff Trawick [EMAIL PROTECTED] writes:
Justin Erenkrantz [EMAIL PROTECTED] writes:
One so far in /usr/local/apache/corefiles/httpd.core.1, but I'm not
sure how this even happened:
I looked at this today. It is an oldie but a goodie. We've been
getting these very infrequently as long
Justin Erenkrantz [EMAIL PROTECTED] writes:
One so far in /usr/local/apache/corefiles/httpd.core.1, but I'm not
sure how this even happened:
I looked at this today. It is an oldie but a goodie. We've been
getting these very infrequently as long as we've been running 2.0 on
daedalus.
How
...in /usr/local/apache2_0_31/corefiles/httpd.core.1
#0 0x2815c990 in kill () from /usr/lib/libc.so.4
#1 0x28198a7e in abort () from /usr/lib/libc.so.4
#2 0x806836e in ap_log_assert (szExp=0x8082359 totalread 0,
szFile=0x8082284 http_protocol.c, nLine=664) at log.c:586
#3 0x805ed10 in
On Sun, Feb 03, 2002 at 09:40:31AM -0800, Justin Erenkrantz wrote:
Oh, no. That assert should be = 0. I wanted to limit -1 brigades
not 0-length ones. *sigh*
I hate asserts. I don't even know why I put it in there. This is
exactly why it is a bad idea to have debug asserts change
On Sun, 3 Feb 2002, Justin Erenkrantz wrote:
I hate asserts. I don't even know why I put it in there. This is
exactly why it is a bad idea to have debug asserts change code.
Seriously.
How about rolling .32 as the same as .31 with that line changed?
(Could you make this change on
On Sun, Feb 03, 2002 at 01:28:44PM -0500, Cliff Woolley wrote:
How about rolling .32 as the same as .31 with that line changed?
(Could you make this change on daedalus - that should fix it.)
Well, it's an AP_DEBUG_ASSERT, so it only breaks in maintainer mode,
right? So IMO it's not worth
Cliff Woolley wrote:
On Sun, 3 Feb 2002, Justin Erenkrantz wrote:
I hate asserts. I don't even know why I put it in there. This is
exactly why it is a bad idea to have debug asserts change code.
Seriously.
...but if totalread had been -1?
How about rolling .32 as the same as
On Sun, 3 Feb 2002, Ian Holsman wrote:
While I'm not on the showstopper bandwagon, I'm wondering what the
chances are of getting some packaging issues* handled in a 2.0.32
before somebody destabilizes the codebase.
I was thinking about this. seeing how noone likes the idea of retagging
Cliff Woolley wrote:
Well, it's an AP_DEBUG_ASSERT, so it only breaks in maintainer mode,
right? So IMO it's not worth a rerelease just for that. If you're
willing to run in maintainer mode, it means you're willing to deal with
this sort of thing. Post a patch in the release notes, and
Jeff Trawick wrote:
Was this during the time you were playing?
[EMAIL PROTECTED] (Cron Daemon) writes:
at 17 Jan 2002 01:30:00 -
core dump found in /tmp/httpd.core
yep. From vi'ing the dump: /usr/local/apache2_0_28-logcpu/conf/httpd.conf,
which was running before I started last
11 matches
Mail list logo
