Re: 2.0.31 coredump on daedalus
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 that should be > good enough. > +1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: 2.0.31 coredump on daedalus
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 > the 2 files to .31. > I was going to propose that v.32 == v.31 +binbuild.sh and the assert > fix. otherwise they go in the 'README.FIRST' file > > and we just go straight to beta with that, as that is what daedalus is > running and everyseems ok with v31, and the 2 patches anyway And the Netware fix, perhaps? That's fine with me. I was just saying if _all_ we were going to do was the assert fix, it wasn't necessary. But if we want the binbuild.sh and Netware patches in a beta as well, v32 sounds reasonable.n --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.31 coredump on daedalus
Jeff Trawick wrote: > Aaron Bannert <[EMAIL PROTECTED]> writes: > > >>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 code. Oh, >>>man. >>> >>>How about rolling .32 as the same as .31 with that line changed? >>>(Could you make this change on daedalus - that should fix it.) >>> >>Unfortunately, I would have to consider this a showstopper. OTOH, >>I'm fully in favor of retagging .32 with this change and the Netware >>change bumped from .31 and rerolling right away. >> > > 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 the 2 files to .31. I was going to propose that v.32 == v.31 +binbuild.sh and the assert fix. otherwise they go in the 'README.FIRST' file and we just go straight to beta with that, as that is what daedalus is running and everyseems ok with v31, and the 2 patches anyway > > *binbuild: statically-linked utilities, our own expat >
Re: 2.0.31 coredump on daedalus
Aaron Bannert <[EMAIL PROTECTED]> writes: > 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 code. Oh, > > man. > > > > How about rolling .32 as the same as .31 with that line changed? > > (Could you make this change on daedalus - that should fix it.) > > Unfortunately, I would have to consider this a showstopper. OTOH, > I'm fully in favor of retagging .32 with this change and the Netware > change bumped from .31 and rerolling right away. 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. *binbuild: statically-linked utilities, our own expat -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: 2.0.31 coredump on daedalus
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 .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? agreed. So far we've only gotten one dump on daedalus, where we intentionally turn on maintainer mode and which we watch pretty closely. Brian's pager isn't going off, nobody has complained, no biggee I say. > So IMO it's not worth a rerelease just for that. I dunno, it seems pretty minor to me. But OTOH 2.0.28 didn't have it. I will patch, rebuild, test & bounce soon. Greg
Re: 2.0.31 coredump on daedalus
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 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 that should be > good enough. Yup. Yeah, that's my take on it. I'm adding a vote to STATUS now whether this merits a bump. If you are running with AP_DEBUG_ASSERTs, you can probably read the release notes. =) -- justin
Re: 2.0.31 coredump on daedalus
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 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 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 that should be good enough. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: 2.0.31 coredump on daedalus
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 code. Oh, > man. > > How about rolling .32 as the same as .31 with that line changed? > (Could you make this change on daedalus - that should fix it.) Unfortunately, I would have to consider this a showstopper. OTOH, I'm fully in favor of retagging .32 with this change and the Netware change bumped from .31 and rerolling right away. -aaron
Re: 2.0.31 coredump on daedalus
On Sun, Feb 03, 2002 at 12:24:21PM -0500, Greg Ames wrote: > (gdb) p r->the_request > $1 = 0x813f7f8 "POST / HTTP/1.1" > (gdb) p r->hostname > $2 = 0x8140370 "search.apache.org" > (gdb) fr 3 > #3 0x805ed10 in ap_http_filter (f=0x8140388, b=0x813f798, > mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=29) > at http_protocol.c:664 > 664 AP_DEBUG_ASSERT(totalread > 0); > (gdb) list > 659 /* How many bytes did we just read? */ > 660 apr_brigade_length(b, 0, &totalread); > 661 > 662 /* If this happens, we have a bucket of unknown length. Die because > 663 * it means our assumptions have changed. */ > 664 AP_DEBUG_ASSERT(totalread > 0); #3 0x805ed10 in ap_http_filter (f=0x8140388, b=0x813f798, mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=29) at http_protocol.c:664 664 AP_DEBUG_ASSERT(totalread > 0); (gdb) print totalread $1 = 0 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 code. Oh, man. How about rolling .32 as the same as .31 with that line changed? (Could you make this change on daedalus - that should fix it.) -- justin
