You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Arild Fines <ar...@broadpark.no> on 2002/06/21 19:40:53 UTC
Problems with mod_dav_svn.so on Windows
Environment: Windows XP Pro, VS.NET Pro(Academic) with debug builds of
Apache 2.0.40 and Subversion ~revision 2300
I am trying to get the Subversion server component working on Windows XP.
However, Apache crashed consistently with a debug assertion when I tried to
check out a repository.
With a little work, I found that the core of the problem was in these lines
in svn_fs__get_node_revision(nodes-table.c in libsvn_fs):
db_err = fs->nodes->get (fs->nodes, trail->db_txn,
svn_fs__id_to_dbt (&key, id, trail->pool),
svn_fs__result_dbt (&value),
0);
svn_fs__track_dbt (&value, trail->pool);
The relevant part of svn_fs_track_dbt(dbt.c) looks like this:
apr_pool_cleanup_register (pool, dbt->data, apr_free_cleanup,
apr_pool_cleanup_null);
This appears to be a Berkeley DB lookup, followed by assigning a clean up
handler to the 'value' returned by BDB. Stepping further in, it seems that
the assigned clean up handler merely calls free on its
argument(value->data). Apache calls all these handlers after the request has
been served by mod_dav_svn.so, and it is inside this particular clean up
handler the assertion is raised.
It seems that even the Debug configuration for the mod_dav_svn VC++ project
links to the import library for libdb40.dll(Release build) instead of the
one for libdb40d.dll(Debug build). I am guessing that this causes
value->data to be allocated by the normal/release version of malloc() inside
the release build of the BDB .dll(looking at BDB source seems to confirm
this), while the clean_up handler calls the debug version of free(), thereby
causing the assertion since they were not allocated from the same heap.
I changed the VC++ project to link against libdb40d.lib instead of
libdb40.lib, and now everything works fine.
Arild Fines
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with mod_dav_svn.so on Windows
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Fri, Jun 21, 2002 at 09:54:47PM +0200, Branko Cibej wrote:
>
>
>>So, the problem is that we link the release BDB into the debug
>>mod_dav_svn.so? Indeed, you're right! Thanks for the report, I'll fix
>>that ASAP.
>>
>>
>
>Hey... I bet a .dsp generator wouldn't flub that up...
>
>*prod prod*
>
>:-)
>
>
I've got other fish to fry, as I'm sure you know.
Such as generating XML from mod_dav_svn. :-P
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with mod_dav_svn.so on Windows
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 21, 2002 at 09:54:47PM +0200, Branko Cibej wrote:
> So, the problem is that we link the release BDB into the debug
> mod_dav_svn.so? Indeed, you're right! Thanks for the report, I'll fix
> that ASAP.
Hey... I bet a .dsp generator wouldn't flub that up...
*prod prod*
:-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with mod_dav_svn.so on Windows
Posted by Branko Čibej <br...@xbc.nu>.
So, the problem is that we link the release BDB into the debug
mod_dav_svn.so? Indeed, you're right! Thanks for the report, I'll fix
that ASAP.
In the meantime, go ahead and use the release mod_dav_svn.so -- it's
working fairly well for me.
Arild Fines wrote:
>Environment: Windows XP Pro, VS.NET Pro(Academic) with debug builds of
>Apache 2.0.40 and Subversion ~revision 2300
>
>I am trying to get the Subversion server component working on Windows XP.
>However, Apache crashed consistently with a debug assertion when I tried to
>check out a repository.
>With a little work, I found that the core of the problem was in these lines
>in svn_fs__get_node_revision(nodes-table.c in libsvn_fs):
>
>db_err = fs->nodes->get (fs->nodes, trail->db_txn,
> svn_fs__id_to_dbt (&key, id, trail->pool),
> svn_fs__result_dbt (&value),
> 0);
>
>svn_fs__track_dbt (&value, trail->pool);
>
>The relevant part of svn_fs_track_dbt(dbt.c) looks like this:
>
>apr_pool_cleanup_register (pool, dbt->data, apr_free_cleanup,
>apr_pool_cleanup_null);
>
>
>This appears to be a Berkeley DB lookup, followed by assigning a clean up
>handler to the 'value' returned by BDB. Stepping further in, it seems that
>the assigned clean up handler merely calls free on its
>argument(value->data). Apache calls all these handlers after the request has
>been served by mod_dav_svn.so, and it is inside this particular clean up
>handler the assertion is raised.
>It seems that even the Debug configuration for the mod_dav_svn VC++ project
>links to the import library for libdb40.dll(Release build) instead of the
>one for libdb40d.dll(Debug build). I am guessing that this causes
>value->data to be allocated by the normal/release version of malloc() inside
>the release build of the BDB .dll(looking at BDB source seems to confirm
>this), while the clean_up handler calls the debug version of free(), thereby
>causing the assertion since they were not allocated from the same heap.
>I changed the VC++ project to link against libdb40d.lib instead of
>libdb40.lib, and now everything works fine.
>
>Arild Fines
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org