After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 674454 - [abrt] Crash in e_book_backend_ldap_authenticate_user
[abrt] Crash in e_book_backend_ldap_authenticate_user
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Contacts
3.4.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2012-04-20 08:37 UTC by Milan Crha
Modified: 2012-11-16 14:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
eds patch (660 bytes, patch)
2012-06-15 14:19 UTC, Milan Crha
committed Details | Review
proposed eds patch ][ (699 bytes, patch)
2012-10-16 09:25 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2012-04-20 08:37:24 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=814341

[abrt] evolution-data-server-3.4.1-1.fc17: Process /usr/libexec/evolution-addressbook-factory was killed by signal 11 (SIGSEGV)


libreport version: 2.0.10
abrt_version:   2.0.10
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-addressbook-factory
comment:        I was just using my Fedora 17 desktop when the
evolution-addressbook-factory program died in the background.
crash_function: e_book_backend_ldap_authenticate_user
executable:     /usr/libexec/evolution-addressbook-factory
kernel:         3.3.1-3.fc17.x86_64
time:           Wed 18 Apr 2012 12:09:07 PM BRT

Core was generated by `/usr/libexec/evolution-addressbook-factory'.
Program terminated with signal 11, Segmentation fault.

Thread 6 (Thread 0x7fcf7aef2700 (LWP 14324))

  • #0 __lll_unlock_wake
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 372
  • #1 _L_unlock_586
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_unlock_usercnt
    at pthread_mutex_unlock.c line 53
  • #3 __pthread_mutex_unlock
    at pthread_mutex_unlock.c line 298
  • #4 g_mutex_unlock
    at gthread-posix.c line 227
  • #5 g_async_queue_unlock
    at gasyncqueue.c line 278
  • #6 g_thread_pool_thread_proxy
    at gthreadpool.c line 306
  • #7 g_thread_proxy
    at gthread.c line 801
  • #8 start_thread
    at pthread_create.c line 309
  • #9 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115

Thread 1 (Thread 0x7fcf90e67700 (LWP 14323))

  • #0 e_book_backend_ldap_authenticate_user
    at e-book-backend-ldap.c line 5143
  • #1 operation_thread
    at e-data-book.c line 237
  • #2 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #3 g_thread_proxy
    at gthread.c line 801
  • #4 start_thread
    at pthread_create.c line 309
  • #5 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115

Comment 1 Milan Crha 2012-06-15 14:19:39 UTC
Created attachment 216517 [details] [review]
eds patch

for evolution-data-server;

With help of data from other downstream bug I found a problem in locking of priv->ldap, which is causing this crash (there were, in certain cases, too many unlocks on a global mutex, causing concurrent access to priv->ldap, which can be accessed only by one caller in a time).
Comment 2 Milan Crha 2012-06-15 14:28:06 UTC
The code in master changed that much that this is applicable only to stable version (the master has it done differently), thus:

Created commit 8825c22 in eds gnome-3-4 (3.4.3+)
Comment 3 Milan Crha 2012-06-15 14:29:26 UTC
*** Bug 641825 has been marked as a duplicate of this bug. ***
Comment 4 Tadej Janež 2012-09-17 08:22:42 UTC
Milan,

I've reproduced this on my Fedora 17 machine with evolution-data-server-3.4.4-2.fc17.x86_64.
If I understand things correctly, this version of E-D-S should contain your fix?

ABRT has detected that my bug is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=814341, which in turn points here.

Retrace report: https://retrace.fedoraproject.org/faf/reports/2824/
Comment 5 Milan Crha 2012-09-17 13:18:04 UTC
Thanks for the update. You are right, this is supposed to be fixed in 3.4.3+, thus in 3.4.4 as well. Maybe a stupid question, but did you restart evolution-addressbook-factory process after updating evolution-data-server? The update doesn't do it on its own, even it's necessary to start using latest binaries.
Comment 6 Tadej Janež 2012-09-18 09:42:55 UTC
Yes, I restarted the evolution-addressbook-factory process.

The thing is that I used preupgrade to upgrade from Fedora 16 to Fedora 17. So I directly upgraded from evolution-data-server 3.2.x to 3.4.4 and I had to restart the system to boot into Fedora 17.
Comment 7 Tadej Janež 2012-10-15 12:11:43 UTC
Milan,

I'm still seeing ABRT crash reports every couple of days,
with evolution-data-server-3.4.4-2.fc17.x86_64 and also evolution-data-server-3.4.4-3.fc17.x86_64. See:
https://retrace.fedoraproject.org/faf/reports/11390/

Is it worth reopening the bug?
Comment 8 Milan Crha 2012-10-16 08:51:43 UTC
Oh, I see it now, it's the auth_method being NULL. I found the other issue, but it was unrelated to this one, after all. I'm reopening the bug.
Comment 9 Tadej Janež 2012-10-16 08:59:19 UTC
OK. Do you need more information from me?
Comment 10 Milan Crha 2012-10-16 09:25:46 UTC
Created attachment 226531 [details] [review]
proposed eds patch ][

for evolution-data-server;

This should either fix or workaround the crash, but I'm not sure which of these two it is. I'm also building a scratch build [1] with the patch included for testing. After its installation a restart of evolution-addressbook-factory process is required. I'm only afraid it's just a workaround, not fixing the cause of the error. For checking that, could you do two things, please?
a) get your LDAP books configuration with:
   $ gconftool-2 --get /apps/evolution/addressbook/sources | grep ldap
   each <source> should have filled "auth" property. Feel free to paste
   the result of the command here, only change server names/addresses/any
   other private information in it, to not expose it publicly.
b) run the factory process on console like this:
   $ /usr/libexec/evolution-addressbook-factory -w &>log.txt
   and then try to keep using it, to reproduce the crash - or at least use
   it until the log.txt file will not contain any critical runtime warnings,
   which may cause the auth_method being NULL probably. The key thing is
   to remember what you did in evolution, for a reproducer purposes.

Please note that when you'll play with the addressbook factory then the evolution itself should be stopped, same as any other evolution processes (you can find them with command like: ps ax | grep evolution).

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4594195
Comment 11 Tadej Janež 2012-10-16 09:32:42 UTC
Ok, I'll follow your instructions and let you know how it goes.
Comment 12 Tadej Janež 2012-10-23 09:19:51 UTC
Today I tried following your instructions.

(In reply to comment #10)
> I'm also building a scratch build [1] with the patch included for
> testing. After its installation a restart of evolution-addressbook-factory
> process is required.

I installed the eds RPM from koji and restarted the computer.

> a) get your LDAP books configuration with:
>    $ gconftool-2 --get /apps/evolution/addressbook/sources | grep ldap
>    each <source> should have filled "auth" property. Feel free to paste
>    the result of the command here, only change server names/addresses/any
>    other private information in it, to not expose it publicly.

This is the output:
<group uid="1100798704.4069.3@tlinux-stable" name="On LDAP Servers" base_uri="ldap://" readonly="no"><source uid="1100798704.4069.6@tlinux-stable" name="Verisign" relative_uri="directory.verisign.com:389/??one"><properties><property name="limit" value="100"/></properties></source></group>

I don't have any LDAP servers set up, so this is not very interesting...

> b) run the factory process on console like this:
>    $ /usr/libexec/evolution-addressbook-factory -w &>log.txt
>    and then try to keep using it, to reproduce the crash - or at least use
>    it until the log.txt file will not contain any critical runtime warnings,
>    which may cause the auth_method being NULL probably. The key thing is
>    to remember what you did in evolution, for a reproducer purposes.

After restart, I killed all evolution* processes. Then I used the command you provided to start evolution-addressbook-factory.
Unfortunately, the evolution-addressbook-factory process I started just ended after ~0.5h and a new process spun up in the background. I'm puzzled why this has happened?

This is the contents of log.txt file:
EDataFactory is now online.
Registering EBookBackendWebdavFactory ('webdav')
Registering EBookBackendLDAPFactory ('ldap')
Registering EBookBackendVCFFactory ('vcf')
Registering EBookBackendFileFactory ('local')
Registering EBookBackendGoogleFactory ('google')
Server is up and running...
Bus name 'org.gnome.evolution.dataserver.AddressBook3' acquired.
Bye.

Milan, does this make any sense to you?
Comment 13 Milan Crha 2012-10-23 12:31:08 UTC
Thanks for the update. I see from the GConf key that the "auth" property is missing, which is what I thought of. You can edit the addressbook, and change the authentication method to some other and back and save it, then the GConf key will change. I also see that you use "one" for level searching, while I usually set "Sub", but it may depend on the server itself, which value is supposed to be there. You can change it on the second tab in properties of the address book. You may want to set search base as well, by clicking the button and choosing the right one. After that the addressbook factory will need a restart.

It closes itself if there are no users of it for about 10 seconds. You can use -r instead of -w in the command, which will prevent it from closing.
Comment 14 Milan Crha 2012-10-23 12:44:51 UTC
I see the LDAP server doesn't have search base defined, though it also doesn't search for me, not in a way of returning any contacts for my name :)
Comment 15 Milan Crha 2012-11-15 08:09:23 UTC
Ping Tadej, did you find any time to test this, please?
Comment 16 Tadej Janež 2012-11-15 10:51:19 UTC
Milan,

(In reply to comment #15)
> Ping Tadej, did you find any time to test this, please?

thanks for the ping.

I've been using evolution-data-server-3.4.4-3.1.fc17.x86_64 since Oct 23 and I haven't seen any crash report in ABRT. So I would say it fixes (or works around) the problem.

(In reply to comment #13)

Firstly, a general comment about this LDAP addressbook. I'm 99% sure that I haven't added the Verisign LDAP addressbook myself. I'm a (very) long-time Evolution user (since version 1.0.3, shipped in Red Hat Linux 7.3) and I've always done upgrades. If I remember correctly, some upgrade added the Verisign address book by itself.

> Thanks for the update. I see from the GConf key that the "auth" property is
> missing, which is what I thought of. You can edit the addressbook, and change
> the authentication method to some other and back and save it, then the GConf
> key will change.

In the "Address Book Properties" dialog box, the Login method is "Anonymously".

I also see that you use "one" for level searching, while I
> usually set "Sub", but it may depend on the server itself, which value is
> supposed to be there. You can change it on the second tab in properties of the
> address book. You may want to set search base as well, by clicking the button
> and choosing the right one. After that the addressbook factory will need a
> restart.

The thing is that I haven't set up this values and I don't know what they mean :).

I can keep the Verisign LDAP Addressbook if you need me to do some more test, otherwise I'll just delete it since I don't use it.

 
> It closes itself if there are no users of it for about 10 seconds. You can use
> -r instead of -w in the command, which will prevent it from closing.

Aha, ok, thanks for the explanation!

What do you think of all this?
Comment 17 Milan Crha 2012-11-16 09:02:36 UTC
Thanks for the update and testing. I'm committing the second patch. I keep the decision whether to delete or not the Verisign addressbook up to you, but if you are not using it, then it's probably safe to delete it. The 3.6.0+ sources changes in this part, but I applied a similar fix to those versions.

Created commit 41c0d9d in eds master (3.7.2+)
Created commit 420a95c in eds gnome-3-6 (3.6.3+)
Comment 18 Tadej Janež 2012-11-16 14:13:42 UTC
Milan, thanks for fixing this!