Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
Hello Bernhard, Am Tue, 19 Nov 2019 11:55:54 +0100 schrieb Bernhard Übelacker : > just a wild guess - is claws-mail doing these ldap queries > in parallel in different threads? This in combination with > the unsteady connection to the server could make two threads > operate on the same structures? An interesting idea! I could imagine, that claws-mail's maintainer will appreciate this hint. (I guess, I will open a bug report against claws-mail upstream) > In that case following gdb output would show all > threads with their backtraces: > (gdb) thread apply all bt indeed this was the command, that I used to generate the gdb output. > Or with showing also the variables: > (gdb) thread apply all bt full Next time I will also use this one. > And how do you get the backtraces? Are you running > with a gdb attached to it permanently? Yes, I am doing this for claws-mail at the moment. > Then you could create a core when the crash happened with > (gdb) generate-core-file /home/someone/corefile Good point - I will try this next time. Thank you for your hints! Cheers, Lars
Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
Hello Lars, just a wild guess - is claws-mail doing these ldap queries in parallel in different threads? This in combination with the unsteady connection to the server could make two threads operate on the same structures? In that case following gdb output would show all threads with their backtraces: (gdb) thread apply all bt Or with showing also the variables: (gdb) thread apply all bt full And how do you get the backtraces? Are you running with a gdb attached to it permanently? Then you could create a core when the crash happened with (gdb) generate-core-file /home/someone/corefile Otherwise you could have a look at a coredump collector like systemd-coredump and its setting Storage=external. With these files someone could examine them later for some more details, if the matching package and dbgsyms are installed. Kind regards, Bernhard
Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
Hello,
thank you for your quick and helpful responses!
Am Sun, 17 Nov 2019 10:33:10 -0800
schrieb Ryan Tandy :
> On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:
> > #0 0xb77acbea in ldap_unbind_ext () at
> > /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2
>
> Please could you install libldap-2.4-2-dbgsym and obtain the backtrace again:
> [..]
I did this now. Thank you for the hint.
> >** (claws-mail:10224): WARNING **: 11:06:04.004: [11:06:04] LDAP error
> >(search): -1 (Unknown error)
>
> Is it possible your LDAP server became temporarily unreachable? I am not
> ruling out a bug in libldap but I also wonder whether claws might have an
> issue in its error handling and somehow pass an invalid argument to a libldap
> function.
Interesting!
Indeed this LDAP server is quite often not reachable (local to one site).
I just tried for a few times to reproduce the issue (accessing the LDAP-based
addressbook in claws-mail, while disconnecting the VPN), but I failed.
In fact: the issue happened only once during the last three months.
Thus I guess, the dbgsym-enhanced stack trace will take a bit of time ...
> Any info you can provide that leads to reproducing the error above (which I
> assume is related), or the crash itself, would be appreciated.
I am sorry, I cannot remember any details.
> On Sun, 17 Nov 2019 10:33:10 -0800 Ryan Tandy wrote:
> > On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:
> [...]
> but I think that last address translates to:
>
> 0x.bea in ldap_unbind_ext at unbind.c:46
>
> That would be that line:
>
> 46 assert( LDAP_VALID( ld ) );
>
> Therefore this function might have received ld pointing to
> existing memory, but the ld->ldc might point to an invalid address.
Thank you for digging deeper!
I took a look at the source code of claws-mail related to "ldap_unbind":
$ grep -B 1 -r ldap_unbind
src/ldaputil.h-#define LDAP_CONST const
src/ldaputil.h:#define ldap_unbind_ext(ld,x,y) ldap_unbind_s(ld)
--
src/ldapquery.c-if( qry->ldap ) {
src/ldapquery.c:rc = ldap_unbind_ext( qry->ldap, NULL, NULL );
--
src/ldapserver.c- cm_return_if_fail(ld != NULL);
src/ldapserver.c: rc = ldap_unbind_ext(ld, NULL, NULL);
These pieces look innocent to me at the first glance. But I am not a user of
the LDAP library, thus I cannot tell.
I am afraid, that it will be hard to find the source of the problem without
further information from another more detailed stack trace. Thus in case you are
running out of ideas at the moment, then I would suggest to just wait and hope
for another stack trace or just close the bug report in a few month otherwise.
Thank you for your time!
Cheers,
Lars
Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
Control: tag -1 moreinfo On Tue, Nov 19, 2019 at 02:40:25AM +0100, de...@sumpfralle.de wrote: I am afraid, that it will be hard to find the source of the problem without further information from another more detailed stack trace. Thus in case you are running out of ideas at the moment, then I would suggest to just wait and hope for another stack trace or just close the bug report in a few month otherwise. Tagging moreinfo based on that. Please feel free to untag it once any more details are available. I'll look at claws-mail but I'm not confident of being able to make progress without steps to reproduce. Thank you!
Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
On Sun, 17 Nov 2019 10:33:10 -0800 Ryan Tandy wrote: > On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote: > > #0 0xb77acbea in ldap_unbind_ext () at > > /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 > > Please could you install libldap-2.4-2-dbgsym and obtain the backtrace > again: > > https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols > Hello Lars, hello Ryan, having a proper backtrace with symbols installed would be better, but I think that last address translates to: 0x.bea in ldap_unbind_ext at unbind.c:46 That would be that line: 46 assert( LDAP_VALID( ld ) ); Therefore this function might have received ld pointing to existing memory, but the ld->ldc might point to an invalid address. So having that crash with gdb attached, the output of following commands might be interesting too: print ld print ld->ldc print *ld print *(ld->ldc) Kind regards, Bernhard
Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
Hello Lars, On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote: #0 0xb77acbea in ldap_unbind_ext () at /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 Please could you install libldap-2.4-2-dbgsym and obtain the backtrace again: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols ** (claws-mail:10224): WARNING **: 11:06:04.004: [11:06:04] LDAP error (search): -1 (Unknown error) Is it possible your LDAP server became temporarily unreachable? I am not ruling out a bug in libldap but I also wonder whether claws might have an issue in its error handling and somehow pass an invalid argument to a libldap function. Any info you can provide that leads to reproducing the error above (which I assume is related), or the crash itself, would be appreciated. thanks, Ryan
Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"
Package: libldap-2.4-2 Version: 2.4.48+dfsg-1+b2 Severity: normal Dear Maintainer, I am using claws-mail from Debian testing on i386. >From time to time claws-mail crashes. Thus I started collecting stack traces. Attached you find a stack trace involving "libldap_r". The most relevant lines should be the following: #0 0xb77acbea in ldap_unbind_ext () at /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 #1 0x0821e4b8 in ldapqry_disconnect (qry=qry@entry=0x9164950) at ldapquery.c:745 #2 0x08220256 in ldapqry_perform_search (qry=0x9164950) at ldapquery.c:914 #3 0x08220256 in ldapqry_search (qry=0x9164950) at ldapquery.c:950 #4 0xb772efb9 in start_thread (arg=) at pthread_create.c:486 #5 0xb6430dc6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 Thank you for your time! Cheers, Lars -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 5.2.0-2-686-pae (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect LSM: AppArmor: enabled Versions of packages libldap-2.4-2 depends on: ii libc6 2.29-3 ii libgnutls30 3.6.10-4 ii libldap-common 2.4.48+dfsg-1 ii libsasl2-2 2.1.27+dfsg-1 libldap-2.4-2 recommends no packages. libldap-2.4-2 suggests no packages. -- no debconf information [New Thread 0xa94d9b40 (LWP 14797)] ** (claws-mail:10224): WARNING **: 11:06:04.004: [11:06:04] LDAP error (search): -1 (Unknown error) Thread 155 "claws-mail" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xa94d9b40 (LWP 14797)] 0xb77acbea in ldap_unbind_ext () from /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 (gdb) thread apply all bt Thread 155 (Thread 0xa94d9b40 (LWP 14797)): #0 0xb77acbea in ldap_unbind_ext () at /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 #1 0x0821e4b8 in ldapqry_disconnect (qry=qry@entry=0x9164950) at ldapquery.c:745 #2 0x08220256 in ldapqry_perform_search (qry=0x9164950) at ldapquery.c:914 #3 0x08220256 in ldapqry_search (qry=0x9164950) at ldapquery.c:950 #4 0xb772efb9 in start_thread (arg=) at pthread_create.c:486 #5 0xb6430dc6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 Thread 6 (Thread 0xb0effb40 (LWP 10278)): #0 0xb7fd5871 in __kernel_vsyscall () #1 0xb64268b3 in __GI___poll (timeout=-1, nfds=2, fds=0xb05097b0) at ../sysdeps/unix/sysv/linux/poll.c:29 #2 0xb64268b3 in __GI___poll (fds=0xb05097b0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:26 #3 0xb6d93ae0 in g_poll () at /usr/lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb6d84673 in () at /usr/lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb6d847b4 in g_main_context_iteration () at /usr/lib/i386-linux-gnu/libglib-2.0.so.0 #6 0xb6d84810 in () at /usr/lib/i386-linux-gnu/libglib-2.0.so.0 #7 0xb6dad7c6 in () at /usr/lib/i386-linux-gnu/libglib-2.0.so.0 #8 0xb772efb9 in start_thread (arg=) at pthread_create.c:486 #9 0xb6430dc6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 Thread 2 (Thread 0xb2707b40 (LWP 10235)): #0 0xb7fd5871 in __kernel_vsyscall () #1 0xb642982b in __GI___select (timeout=0xb2706c84, exceptfds=0x0, writefds=0x0, readfds=0xb2706c8c, nfds=37) at ../sysdeps/unix/sysv/linux/select.c:41 #2 0xb642982b in __GI___select (nfds=37, readfds=0xb2706c8c, writefds=0x0, exceptfds=0x0, timeout=0xb2706c84) at ../sysdeps/unix/sysv/linux/select.c:37 #3 0xb6a05102 in () at /usr/lib/i386-linux-gnu/libetpan.so.20 #4 0xb6a02c2f in mailstream_low_read () at /usr/lib/i386-linux-gnu/libetpan.so.20 #5 0xb6a04128 in mailstream_feed_read_buffer () at /usr/lib/i386-linux-gnu/libetpan.so.20 #6 0xb6a021ee in mailstream_read_line_append () at /usr/lib/i386-linux-gnu/libetpan.so.20 #7 0xb6a02285 in mailstream_read_line () at /usr/lib/i386-linux-gnu/libetpan.so.20 #8 0xb6a0d3de in mailimap_read_line () at /usr/lib/i386-linux-gnu/libetpan.so.20 #9 0xb6a0e158 in mailimap_noop () at /usr/lib/i386-linux-gnu/libetpan.so.20 #10 0x0822ee47 in noop_run (op=0x910d910) at imap-thread.c:1133 #11 0x0825de19 in thread_run (data=0x8ed1c70) at etpan-thread-manager.c:340 #12 0xb772efb9 in start_thread (arg=) at pthread_create.c:486 #13 0xb6430dc6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 Thread 1 (Thread 0xb323d7c0 (LWP 10224)): #0 0xb7fd5871 in __kernel_vsyscall () #1 0xb641f064 in __GI___libc_open (file=0x8a4b190 "/home/lars/.claws-mail/addrbook/addrbook-09.xml.tmp", oflag=) at ../sysdeps/unix/sysv/linux/open.c:44 #2 0xb63abd5b in __GI__IO_file_open (fp=0x98c9620, filename=0x8a4b190 "/home/lars/.claws-mail/addrbook/addrbook-09.xml.tmp", posix_mode=577, prot=438, read_write=4, is32not64=0) at fileops.c:189 --Type for more, q to quit, c to continue without paging--c #3 0xb63abf3f in _IO_new_file_fopen
