[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Segfault in svnserve on UB 16.04 LTS sometimes

From: Thorsten Schöning <tschoening_at_am-soft.de>
Date: Fri, 12 Apr 2019 16:25:33 +0200

Guten Tag Stefan Sperling,
am Freitag, 12. April 2019 um 11:45 schrieben Sie:

> Install a package with debug symbols, enable core dumps, and get
> a backtrace with gdb from a core dump.

Does the following help? I've attched some more verbose chrashlog
but without the actual dump, as that is some MiB in size. I can upload
that somewhere if it's considered necessary.

Looks to me like baton has already been freed before without NULLing
and is now illegally accessed again? Still don't know which repo and
operation triggers that.

> Stacktrace:
> #0 object_ref_cleanup (baton=0x7f5f75994f00) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/libsvn_subr/object_pool.c:148
> object = 0x7f5f75994f00
> object_pool = <optimized out>
> #1 0x00007f5f747e4e3e in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> No symbol table info available.
> #2 0x00007f5f747e4e15 in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> No symbol table info available.
> #3 0x0000000000406e4e in main (argc=<optimized out>, argv=0x7ffddc135568) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/svnserve/svnserve.c:1368
> pool = 0x7f5f759d6028
> exit_code = 0
> err = <optimized out>
> StacktraceAddressSignature: /usr/bin/svnserve:11:/usr/lib/x86_64-linux-gnu/libapr-1.so.0.5.2+1ae3e:/usr/lib/x86_64-linux-gnu/libapr-1.so.0.5.2+1ae15:/usr/bin/svnserve+6e4e
> StacktraceSource:
> #0 object_ref_cleanup (baton=0x7f5f75994f00) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/libsvn_subr/object_pool.c:148
> 143: */
> 144: static apr_status_t
> 145: object_ref_cleanup(void *baton)
> 146: {
> 147: object_ref_t *object = baton;
> 148: svn_object_pool__t *object_pool = object->object_pool;
> 149:
> 150: /* If we released the last reference to object, there is one more
> 151: unused entry.
> 152:
> 153: Note that unused_count does not need to be always exact but only
> #1 0x00007f5f747e4e3e in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> #2 0x00007f5f747e4e15 in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> #3 0x0000000000406e4e in main (argc=<optimized out>, argv=0x7ffddc135568) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/svnserve/svnserve.c:1368
> 1363: if (threads)
> 1364: apr_thread_pool_destroy(threads);
> 1365: #endif
> 1366:
> 1367: /* this will also close the server's socket */
> 1368: svn_pool_destroy(pool);
> 1369: return exit_code;
> 1370: }
>
> StacktraceTop:
> object_ref_cleanup (baton=0x7f5f75994f00) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/libsvn_subr/object_pool.c:148
> apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> main (argc=<optimized out>, argv=0x7ffddc135568) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/svnserve/svnserve.c:1368
> ThreadStacktrace:
> .
> Thread 1 (Thread 0x7f5f759c9780 (LWP 3769)):
> #0 object_ref_cleanup (baton=0x7f5f75994f00) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/libsvn_subr/object_pool.c:148
> object = 0x7f5f75994f00
> object_pool = <optimized out>
> #1 0x00007f5f747e4e3e in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> No symbol table info available.
> #2 0x00007f5f747e4e15 in apr_pool_destroy () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
> No symbol table info available.
> #3 0x0000000000406e4e in main (argc=<optimized out>, argv=0x7ffddc135568) at /build/subversion-8E3yhQ/subversion-1.9.3/subversion/svnserve/svnserve.c:1368
> pool = 0x7f5f759d6028
> exit_code = 0
> err = <optimized out>

Some background for at least my docs:

UB 16.04 seems to generate core dumps for this package by default
already, there still was one from the last crash in /var/crash without
me dealing with "ulimit" or whatever[1]:

> cat /proc/sys/kernel/core_pattern
> |/usr/share/apport/apport %p %s %c %d %P

That crashlog contains a stacktrace and core dump at the end, but as
mentioned, the former is not very useful without symbols. Installing
those is easy:

> sudo apt install subversion-dbg

There's some tool called "apport-retrace" easily putting dependencies,
stacktrace with symbols and code etc. into the crashlog:

> sudo apt install apport-retrace
> apport-retrace -R %f

"-R" is important, because for some reason the crashlog misses the
"Package" directive, which makes the app fail.[2] One can either put
that directive into the file manually or use "-R", which does all
those things.[3] While there's the following warning printed in the
end, the overall crashlog looks pretty good:

> W: Can't drop privileges for downloading as file 'subversion_1.9.3-2ubuntu1.1.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[1]: https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/
[2]: https://askubuntu.com/questions/348790/apport-retrace-fails-with-error-report-file-does-not-contain-one-of-the-require
[3]: http://manpages.ubuntu.com/manpages/xenial/man1/apport-retrace.1.html

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening_at_AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Received on 2019-04-12 16:25:42 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.