subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Should 'svn help' with APR lifetime debug enabled run without issues?
Date Wed, 21 Apr 2021 19:35:50 GMT
Rick van der Zwet wrote on Wed, Apr 21, 2021 at 16:10:57 +0200:
> Hi,
> 
> I debugging crashes within the Trac (https://trac.edgewall.org/) when using
> the svn backend. The issue seems to be related to Apache Portable Runtime
> (APR) pool memory management at Trac together with subversion SWIG python
> bindings and libsvn.
> 
> I am trying to run subverion with APR (lifetime) debugging enabled
> (./configure --enable-pool-debug=all --enable-debug) to give more insights,
> how-ever I got stuck with the basics.

I assume the use of «all» as the argument to --enable-pool-debug is
deliberate?  I.e., that enabling fewer bitflags wouldn't suffice for
your use-case?

> First I tried 'svn' which completes fine:
> 
> Next I tried 'svn help' which gives me apr_pool_integrity check [lifetime]
> exception:
> =======================================================================================================================================================
> POOL DEBUG: [29126/34384113664] CREATEU (         0/         0/      5029)
> 0x80174d640 "subversion/libsvn_subr/pool.c:160"
> <subversion/libsvn_subr/pool.c:160> (0/0/0)
> POOL DEBUG: [29126/34384113664]    LIFE
> 0x80174d640 <memory/unix/apr_pools.c:apr_pool_integrity check [lifetime]>
> 

Looking at that file (in apr-1.6.5, since you didn't mention
a particular version):

  1597	static void apr_pool_check_integrity(apr_pool_t *pool)
  1598	{
  1599	    /* Rule of thumb: use of the global pool is always
  1600	     * ok, since the only user is apr_pools.c.  Unless
  1601	     * people have searched for the top level parent and
  1602	     * started to use that...
  1603	     */
  1604	    if (pool == global_pool || global_pool == NULL)
  1605	        return;
  1606	
  1607	    /* Lifetime
  1608	     * This basically checks to see if the pool being used is still
  1609	     * a relative to the global pool.  If not it was previously
  1610	     * destroyed, in which case we abort().
  1611	     */
  1612	#if (APR_POOL_DEBUG & APR_POOL_DEBUG_LIFETIME)
  1613	    if (!apr_pool_is_child_of(pool, global_pool)) {
  1614	#if (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE_ALL)
  1615	        apr_pool_log_event(pool, "LIFE",
  1616	                           __FILE__ ":apr_pool_integrity check [lifetime]", 0);
  1617	#endif /* (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE_ALL) */
  1618	        abort();
  1619	    }
  1620	#endif /* (APR_POOL_DEBUG & APR_POOL_DEBUG_LIFETIME) */

The Subversion caller is error.c (frame #6), and it has a comment saying
it deliberately uses a pool unrelated to the global pool:

    69	  /* Strictly speaking, this is a memory leak, since we're creating an
    70	     unmanaged, top-level pool and never destroying it.  We do this
    71	     because this pool controls the lifetime of the thread-local
    72	     storage for error locations, and that storage must always be
    73	     available. */

> Program received signal SIGABRT, Aborted.
> 0x0000000801088c2a in thr_kill () from /lib/libc.so.7
> (gdb) bt
> #0  0x0000000801088c2a in thr_kill () from /lib/libc.so.7
> #1  0x0000000801087084 in raise () from /lib/libc.so.7
> #2  0x0000000800ffd279 in abort () from /lib/libc.so.7
> #3  0x0000000800ea8a57 in apr_pool_check_integrity (pool=0x80174d640) at memory/unix/apr_pools.c:1618
> #4  0x0000000800ea8c3d in apr_pcalloc_debug (pool=0x80174d640, size=16,
>     file_line=0x800e7c683 "threadproc/unix/threadpriv.c:28") at memory/unix/apr_pools.c:1795
> #5  0x0000000800ebbe49 in apr_threadkey_private_create (key=0x800873998 <error_file_key>,
>     dest=0x80081d770 <null_threadkey_dtor>, pool=0x80174d640) at threadproc/unix/threadpriv.c:28
> #6  0x000000080081bd61 in locate_init_once (ignored_baton=0x0) at subversion/libsvn_subr/error.c:77
> #7  0x00000008007f6d4e in str_init_func_wrapper (init_baton=0x7fffffffcfb0) at subversion/libsvn_subr/atomic.c:156
> #8  0x00000008007f6bcd in init_once (global_status=0x800873990 <svn_error.locate.init_status>,
>     init_func=0x8007f6d30 <str_init_func_wrapper>, init_baton=0x7fffffffcfb0) at
subversion/libsvn_subr/atomic.c:71
> #9  0x00000008007f6ce0 in svn_atomic__init_once_no_error (global_status=0x800873990 <svn_error.locate.init_status>,
>     str_init_func=0x80081bd30 <locate_init_once>, baton=0x0) at subversion/libsvn_subr/atomic.c:170
> #10 0x000000080081bca7 in svn_error__locate (file=0x8007d85cd "subversion/libsvn_subr/io.c",
line=3988)
>     at subversion/libsvn_subr/error.c:128
> #11 0x000000080082235d in svn_io_file_open (new_file=0x7fffffffd0e8, fname=0x8017523c0
"/etc/subversion/servers",
>     flag=1, perm=4095, pool=0x80174d500) at subversion/libsvn_subr/io.c:3988
⋮
> #18 0x000000000025cc7f in main (argc=2, argv=0x7fffffffdaa0) at subversion/svn/svn.c:3325
> (gdb)
> =======================================================================================================================================================
> 
> 
> I tried subversion 1.14.1 and subversion-trunk@1889032. Traces above are
> generated using the subversion-trunk codebase.
> 
> I have also the unittests of the Apache Portable Runtime (APR) on which the
> relevant(?) ones completes successfully.
> 
> How can I find out if a) I am looking at an potential issue within
> subversion source code, b) whether the APR debugging is flagging this as a
> false positive or c) something else?

I don't have a recommended workaround off the top of my head, sorry.

>

For future reference, your MUA hard-wrapped the various traces, which
made them difficult to read.  Please disable hard wrapping for such
cases, or use attachments named *.txt.

Cheers,

Daniel

Mime
View raw message