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
