apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thang Nguyen <thangk...@yahoo.co.jp>
Subject Re: *** glibc detected *** .double free or corruption
Date Thu, 09 Nov 2006 16:18:11 GMT
2006-11-09 (木) の 10:58 +0000 に Joe Orton さんは書きました:

> Two helpful tricks when tracking down this kind of issue are:
> 
> 1) rebuild your application against an APR configured using 
> --enable-pool-debug; this will help highlight pool issues faster
> 
> 2) run your application with the following environment variable set:
> 
>   export MALLOC_CHECK_=2
> 
> (note the careful placement of the underscores)
> 
> this will mean glibc will do extra heap checking and will abort() sooner 
> when any heap corruption is noticed.
> 
> joe

Thanks Joe.

I will try rebuild apr configured using --enable-pool-debug.

After testing with MALLOC_CHECK_, i had this result:

(In fact, i tested in CGI environment, not fastcgi. Because in fastcgi
environment, it loops and loops... I dont know how to "gracefull" kill
to see the application's cleanup. By the way, i used 100 threads. But
the problem is the same even i changed from 1 to 200 threads)

0) MALLOC_CHECK_ = 0: Nothing happended, the app cleanup did well and
finished without being aborted.
1) MALLOC_CHECK_ = 1: 
//====================
*** glibc detected *** ./webapp.fcgi: free(): invalid pointer:
0x09a08468 ***
*** glibc detected *** ./webapp.fcgi: free(): invalid pointer:
0x09a16fc8 ***
*** glibc detected *** ./webapp.fcgi: free(): invalid pointer:
0x09a295b8 ***
*** glibc detected *** ./webapp.fcgi: free(): invalid pointer:
0x09a16ee0 ***
//====================
I realized that the number of *** glibc detected *** equal to 4 - the
number of the apr_reslist(s) in that time. I guess the problem is in
apr_reslist, but not sure due to my way of creating and freeing it or
something else. Looking in the app log (using log4cpp), the "glibc
dectection" appeared after all the connection destruction as well as
connection objects are deleted, but before freeing apr_reslist(s).

//====================
The log is something like this:
1163088145 INFO Root : Application [pid = 22981, thread_id = 41]
finished!
1163088145 INFO Root : Application [pid = 22981, thread_id = 200]
finished!
1163088145 WARN Root : All threads finished
1163088145 DEBUG  : [_delete_query_object] Deleting sql object
1163088145 DEBUG  : [_delete_query_object] SQLObject deleted
...
1163088145 DEBUG  : [thconn_destruct] Destructing connection newsdb
1163088145 DEBUG  : [thconn_destruct] Connection newsdb deleted
...
1163088145 WARN Root : =========== Application is cleaning up
============
...
1163088145 WARN Root : ============== Application finished
==============
(<------- "Goodbye from ConnPool" is expected here, and just that
message)
------------ End -------------------

//====================
2) MALLOC_CHECK_ = 2:
Not much information, only "Aborted".

Thang



Mime
View raw message