You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Gourlay <go...@BAUERCONTROLS.com> on 2009/05/18 20:59:59 UTC

apr_pcalloc returning memory already in use

I have an application that uses the Subversion client library, and under
certain circumstances Subversion overwrites memory it is already using
and ultimately causes the application process to crash.

 

To cause the crash application calls svn_config_get_config to get the
default configuration, passing in a pool created earlier with
apr_pool_create_ex.  The crash occurs deep within svn_config_get_config,
when it is done reading the user-specific configuration file.  The
function apr_file_read_full reaches the end of the configuration file
and returns an apr error code saying so, and the code uses
do_io_file_wrapper_cleanup to create an svn_error object containing the
eof message.  It calls make_error_internal to create the svn_error,
which creates a new pool with apr_pool_create and allocates the
svn_error object from it with apr_pcalloc.  The address of the memory
returned by apr_pcalloc is the same as the address of the memory
Subversion is already using for the stream baton for the file, and the
contents of the baton are overwritten.

 

I'm using Subversion 1.5.5 in Windows.  The memory is overwritten at
line 92 of libsvn_subr/error.c in the call to apr_pcalloc.   Below is
the call stack from Visual Studio at the point of the error.

 

Is this a known bug?  Is there anything that I can do differently to
circumvent this error?  

 

John Gourlay

 

 

            libsvn_subr-1.dll!make_error_internal(int apr_err=70014,
svn_error_t * child=0x00000000)  Line 92 + 0x16 bytes      C

            libsvn_subr-1.dll!svn_error_wrap_apr(int status=70014, const
char * fmt=0x09898ac0, ...)  Line 161 + 0xb bytes    C

            libsvn_subr-1.dll!do_io_file_wrapper_cleanup(apr_file_t *
file=0x094dfc80, int status=70014, const char * msg=0x09898ac0, const
char * msg_no_name=0x09898aac, apr_pool_t * pool=0x094d1120)  Line 2657
+ 0x30 bytes       C

            libsvn_subr-1.dll!svn_io_file_read_full(apr_file_t *
file=0x094dfc80, void * buf=0x094f2330, unsigned int nbytes=16384,
unsigned int * bytes_read=0x00127b4c, apr_pool_t * pool=0x094d1120)
Line 2718 + 0x2e bytes   C

            libsvn_subr-1.dll!read_handler_apr(void * baton=0x094f1358,
char * buffer=0x094f2330, unsigned int * len=0x00127b4c)  Line 343 +
0x20 bytes C

>          libsvn_subr-1.dll!svn_stream_read(svn_stream_t *
stream=0x094f1360, char * buffer=0x094f2330, unsigned int *
len=0x00127b4c)  Line 97 + 0x16 bytes  C

            libsvn_subr-1.dll!translated_stream_read(void *
baton=0x094da1e8, char * buffer=0x00127b7f, unsigned int *
len=0x00127b80)  Line 1169 + 0x16 bytes           C

            libsvn_subr-1.dll!svn_stream_read(svn_stream_t *
stream=0x094da210, char * buffer=0x00127b7f, unsigned int *
len=0x00127b80)  Line 97 + 0x16 bytes  C

            libsvn_subr-1.dll!parser_getc(parse_context_t *
ctx=0x00127be0, int * c=0x00127b9c)  Line 85 + 0x14 bytes         C

            libsvn_subr-1.dll!skip_whitespace(parse_context_t *
ctx=0x00127be0, int * c=0x00127bd8, int * pcount=0x00127c08)  Line 119 +
0xd bytes     C

            libsvn_subr-1.dll!svn_config__parse_file(svn_config_t *
cfg=0x094dfb78, const char * file=0x094df818, int must_exist=0,
apr_pool_t * pool=0x094d1120)  Line 422 + 0x11 bytes     C

            libsvn_subr-1.dll!svn_config_read(svn_config_t * *
cfgp=0x00127c48, const char * file=0x094df818, int must_exist=0,
apr_pool_t * pool=0x094d1120)  Line 100 + 0x15 bytes   C

            libsvn_subr-1.dll!svn_config_merge(svn_config_t *
cfg=0x094df870, const char * file=0x094df818, int must_exist=0)  Line
310 + 0x18 bytes    C

            libsvn_subr-1.dll!read_all(svn_config_t * * cfgp=0x00127cdc,
const char * sys_registry_path=0x094df4f8, const char *
usr_registry_path=0x094df530, const char * sys_file_path=0x094df678,
const char * usr_file_path=0x094df818, apr_pool_t * pool=0x094d1120)
Line 175 + 0x11 bytes          C

            libsvn_subr-1.dll!get_category_config(svn_config_t * *
cfg=0x00127cdc, const char * config_dir=0x00000000, const char *
category=0x098947f8, apr_pool_t * pool=0x094d1120)  Line 223 + 0x1d
bytes       C

            libsvn_subr-1.dll!svn_config_get_config(apr_hash_t * *
cfg_hash=0x094d1c6c, const char * config_dir=0x00000000, apr_pool_t *
pool=0x094d1120)  Line 246 + 0x16 bytes   C

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2303438

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: apr_pcalloc returning memory already in use

Posted by John Gourlay <go...@BAUERCONTROLS.com>.
What I did wrong to cause this error was to call svn_error_clear on an
svn_error_t structure passed to me in a notification callback.
Apparently Subversion itself was also freeing the memory, and double
freeing corrupts the system heap.

John Gourlay

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359161

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].