On Mon, 22 Nov 2004, Cliff Woolley wrote:
On Mon, 22 Nov 2004, Ronald Park wrote:
I'm investigating a difficult to diagnose problem and I came across the following code in core_output_filter():
Yuck. I HATE the core_output_filter. I probably know that code as well as anybody, and yet every time I look at it, it makes my brain hurt so bad I want to scream. It's just a big pile of jumbled up intertwined heuristics.
I can see I'm going to have to just break down and rewrite the damned thing as a series of (gasp) SMALLER FUNCTIONS, rather than one big monolithic beast.
But first, this bug.
It would be very helpful if you could do one or both of the following:
* compile with bucket debugging enabled (see slide 17 of http://www.cs.virginia.edu/~jcw5q/talks/apache/apache2moddebugging.ppt)
* give me a list of the buckets in each brigade that gets passed in to the core output filter in response to the request that reproduces the problem. (set a breakpoint on the line: 4026 while (b && !APR_BRIGADE_EMPTY(b)) { and then run "dump_brigade b" in gdb each time the breakpoint gets hit)
--Cliff
First, thanks for responding and thanks for the link.
Now, for the bad news: we don't know if there's a specific single request that creates the problem.
In fact, given that it mostly runs fine for many hours without problem implies that it just happens
under production load. So that sort of rules out attaching with gdb... I can't hit enter to conitnue
that fast for that long. :D
Now for the good news: we can probably run in production with debugging enabled (the overhead
for extra debug code executing is probably negligible compared to overall download time for these
huge files :D). So I'll see about getting that out there and report back with any findings.
Thanks again, Ron -- Ronald Park <[EMAIL PROTECTED]>
