You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Alex Dubov <oa...@yahoo.com> on 2006/12/01 08:24:05 UTC
Weird crash in apr_palloc
Greetings.
I'm currently using apr-1.2.7 with apache 2.2.3 and recently encountered a weird bug. I wonder if
somebody have seen something like this before (backtrace at crash point):
#0 0xb7b36462 in malloc_consolidate () from /lib/tls/libc.so.6
#1 0xb7b37422 in _int_malloc () from /lib/tls/libc.so.6
#2 0xb7b39231 in malloc () from /lib/tls/libc.so.6
#3 0xb7c66b70 in pool_alloc (pool=0xfffffff0, size=977)
at memory/unix/apr_pools.c:1287
#4 0xb7c67b97 in apr_palloc (pool=0x80d2b80, size=977)
at memory/unix/apr_pools.c:2242
#5 0xb7edbe52 in dbd_mysql_pvselect (pool=0x80d2b80, sql=0x80b4648,
res=0xbf92f2d4, statement=0x80a6270, random=0, args=0x80d2b80 "�\v\b")
at dbd/apr_dbd_mysql.c:712
#6 0xb7eda944 in apr_dbd_pvselect (driver=0x48, pool=0x80d2b80,
handle=0x80b4648, res=0xbf92f2d4, statement=0x80a6270, random=0)
at dbd/apr_dbd.c:300
#7...
It appears like there's some evil heap corruption or something like this. Nothing interesting
shows in pool debug trace or mysql client trace. If nobody has any idea on what can this be, I'll
have to assume that the memory is somehow corrupted by mysql and go dig there.
The crush is apparently access timing dependent. It may happen in malloc (like presented) or later
in free when pool is destroyed or never happen at all.
I'm using my own apr_dbd_mysql (I posted it here some time before), but I can't see anything
unusual in it.
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Re: Weird crash in apr_palloc - apr_allocator_destroy question
Posted by Alex Dubov <oa...@yahoo.com>.
While debugging heap corruption happening with mod_dbd and apr_dbd_mysql I found a rather weird
problem with apr_allocator_destroy: the tail node of one of the memnode chains has ->next pointing
to itself, causing a free() runaway (this, I believe, corresponds to the apache bug 39985).
I, however, can't see why would this happen. Any ideas are appreciated.
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Re: Weird crash in apr_palloc
Posted by Alex Dubov <oa...@yahoo.com>.
> Yes, this is a classic symptom of heap corruption. Try running with:
>
> export MALLOC_CHECK_=2
>
> and it may crash closer to the actual bug.
>
Apparently, there were two different bugs causing the crash I reported. I was able to work around
one of them by allocating all the needed space for sql results array from the long living pool in
dbd_mysql_prepare (instead of using per-connection pool - it's something mysql related). The other
bug, however left me buffled:
I'm returning apr_dbd_t struct from dbd_mysql_open, say:
apr_dbd_t *handle == 0x80b5610
handle->conn == 0x80b57a0 (db specific handle)
yet, when I get the dbd_mysql_close call, handle->conn is misteriously changed:
apr_dbd_t *handle == 0x80b5610
handle->conn == 0x809db00
(causing another SEGV).
Interestingly enough, when run normally, handle->conn is always NULL (junk value only appears with
httpd -X), so there's no crash, but database handle does not get closed either.
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
Re: Weird crash in apr_palloc
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Nov 30, 2006 at 11:24:05PM -0800, Alex Dubov wrote:
> Greetings.
>
> I'm currently using apr-1.2.7 with apache 2.2.3 and recently encountered a weird bug. I wonder if
> somebody have seen something like this before (backtrace at crash point):
> #0 0xb7b36462 in malloc_consolidate () from /lib/tls/libc.so.6
> #1 0xb7b37422 in _int_malloc () from /lib/tls/libc.so.6
> #2 0xb7b39231 in malloc () from /lib/tls/libc.so.6
> #3 0xb7c66b70 in pool_alloc (pool=0xfffffff0, size=977)
> at memory/unix/apr_pools.c:1287
...
> It appears like there's some evil heap corruption or something like this. Nothing interesting
> shows in pool debug trace or mysql client trace. If nobody has any idea on what can this be, I'll
> have to assume that the memory is somehow corrupted by mysql and go dig there.
Yes, this is a classic symptom of heap corruption. Try running with:
export MALLOC_CHECK_=2
and it may crash closer to the actual bug.
Regards,
joe