[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#205553: Backtrace php4-imap/apache SEGV



On Mon, Feb 02, 2004 at 02:16:48AM +0100, Jeroen van Wolffelaar wrote:
> I have a stable reporduction case now in a chroot, and have succeed in
> getting backtraces out of it.

> It is with a recompiled libssl0.9.7, without the db_strip, to get a more
> useful one. As I don't know much about gdb, any hints on getting better
> backtraces would be appreciated (I now just gdb'd /usr/sbin/apache with
> -X -F)

> The problem is the starting point, mail_getquota. It's an internal
> function in PHP's imap module, used ONLY when the corresponding PHP
> functions are called. However, the SIGSEGV happens at startup, and in ny
> whole fscking chroot there is no single php script anywhere.

> So, it gets wrongly called? Then there must be a serious fuckup of
> symbols somewhere, or otherwise I really don't understand. It also
> states about a possible stack overwrite at the end of the bt, so there
> is an accidental buffer overflow somewhere? Or is this function called
> somehow on startup... that would be really wierd.

There seem to be two problems at work here: one, that in spite of having
recompiled libssl0.9.7, the function names listed appear to be fairly
useless (possibly because the lib was never built with -g in the first
place, so stripping the library or not doesn't make a difference), and
two, that the stack is a royal mess and appears to be at least partially
(if not wholly) corrupted.  For instance, it's a safe bet that
0x00000001 and 0x00000010 appearing on the stack indicates a bug.

This is pretty much in keeping with the other backtraces I've seen of
this bug, which is why (combined with other problems such as apache's
double-initialization startup and the fact that it's not reproducible on
my own systems) it's been so hard to pin down.

> In the case of the buffer overflow, I guess that stack trace is useless
> and just plain wrong?

I wouldn't trust any of the reported stack contents in this case as
indicating the actual source of the bug, no.

Regards,
-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: