httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zero Altitude" <>
Subject Re: BUG: Problem with latest subversion libapreq2 on linux 64 bit amd (segfault accessing handle variable)
Date Thu, 08 May 2008 14:09:58 GMT
It would be difficult at present to get this to run on a developer
test machine, since those are currently not running on AMD64, and this
bug has /never/ happened on other architectures.  Furthermore, if it
really was "something else unrelated clobbering the memory", then it
might be difficult to track it down anyway in a different environment
where those "something else unrelated"s are not around.

Maybe you could give me a little bit more insight into what kinds of
things /could/ be clobbering that memory.  Do you mean other
processes?  Do you mean other parts of the apache process?  Maybe
someone familiar with apreq internals could point me to exactly where
handle is first initialized, and when its status is affected, and I
could proceed simply by putting more debugging information -- I can
certainly reproduce the problem reliably every day, just not in a way
that I can easily debug in realtime.

I apologize that my needs are so specific.  I am beginning to sense
that the problem I am having is fairly unusual, and so pointers to
what I can do in the sources to generate more debugging information
when this problem occurs would be very welcome.  General pointers,
too, as to how handle gets initialized and affected over time in a
threaded environment would be super.

The fact that this only happens on my 64 bit AMD machines seems really
telling to me -- any clues there?


On Thu, May 8, 2008 at 2:49 AM, Bojan Smojver <> wrote:
> On Thu, 2008-05-08 at 02:16 -0400, Zero Altitude wrote:
>  > I apologize: can you clarify the watchpoint suggestion?  If you mean
>  > "while running the program" as in, while apache is still running and
>  > not crashed, this is virtually impossible -- as I said, the segfault
>  > occurs only once in a few thousand uploads.
>  Yes. Obviously, don't use the production machine for this. Rather, set
>  up a test instance somewhere and then hit it with a lot of uploads (you
>  should be able to use ab for that).
>  Watchpoint in GDB enable you to see when things change. Like this:
>  -------------------------------------------------
>  You can use a watchpoint to stop execution whenever the value of an
>  expression changes, without having to predict a particular place where
>  this may happen.  (This is sometimes called a "data breakpoint".)  The
>  expression may be as simple as the value of a single variable, or as
>  complex as many variables combined by operators.  Examples include:
>    * A reference to the value of a single variable.
>    * An address cast to an appropriate data type.  For example, `*(int
>      *)0x12345678' will watch a 4-byte region at the specified address
>      (assuming an `int' occupies 4 bytes).
>    * An arbitrarily complex expression, such as `a*b + c/d'.  The
>      expression can use any operators valid in the program's native
>      language (*note Languages::).
>  -------------------------------------------------
>  So, in your case, see when handle becomes negative. When it does, GDB
>  will stop execution and you'll see what code caused that memory location
>  to change. My bet is that something completely unrelated is stomping
>  over this, thus causing a segfault.
>  --
>  Bojan

View raw message