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=<optimized out>) 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

Hello Lars,

Please could you install libldap-2.4-2-dbgsym and obtain the backtrace
again:

https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

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

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

Control: tag -1 moreinfo

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!

Hello,

thank you for your quick and helpful responses!


Am Sun, 17 Nov 2019 10:33:10 -0800
schrieb Ryan Tandy <ryan@nardis.ca>:

I did this now. Thank you for the hint.
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 ...

I am sorry, I cannot remember any details.

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

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

Hello Bernhard,


Am Tue, 19 Nov 2019 11:55:54 +0100
schrieb Bernhard Übelacker <bernhardu@mailbox.org>:

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)

indeed this was the command, that I used to generate the gdb output.

Next time I will also use this one.

Yes, I am doing this for claws-mail at the moment.

Good point - I will try this next time.


Thank you for your hints!

Cheers,
Lars