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 641825 - Crash in poll_ldap() when finalizing the backend
Crash in poll_ldap() when finalizing the backend
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: 2011-02-08 11:07 UTC by Milan Crha
Modified: 2012-10-17 11:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
eds patch (2.53 KB, patch)
2012-10-17 11:46 UTC, Milan Crha 		committed Details | Review

Description Milan Crha 2011-02-08 11:07:35 UTC 
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=675772

abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: /usr/libexec/e-addressbook-factory
component: evolution-data-server
crash_function: ber_free_buf
executable: /usr/libexec/e-addressbook-factory
kernel: 2.6.38-0.rc3.git0.1.fc15.x86_64
package: evolution-data-server-2.32.1-1.fc14
rating: 4
reason: Process /usr/libexec/e-addressbook-factory was killed by signal 6
(SIGABRT)
release: Fedora release 14 (Laughlin)
time: 1297096884
uid: 500

Core was generated by `/usr/libexec/e-addressbook-factory'.
Program terminated with signal 6, Aborted.

+ Trace 225895

Thread 3 (Thread 28569)

  • #0 ldap_set_option
    from /usr/lib64/evolution-data-server-1.2/extensions/libebookbackendldap.so
  • #1 ldap_init
    from /usr/lib64/evolution-data-server-1.2/extensions/libebookbackendldap.so
  • #2 e_book_backend_ldap_connect
    at e-book-backend-ldap.c line 833
  • #3 e_book_backend_ldap_reconnect
    at e-book-backend-ldap.c line 1034
  • #4 e_book_backend_ldap_authenticate_user
    at e-book-backend-ldap.c line 4872
  • #5 operation_thread
    at e-data-book.c line 106
  • #6 g_thread_pool_thread_proxy
    at gthreadpool.c line 319
  • #7 g_thread_create_proxy
    at gthread.c line 1897
  • #8 start_thread
    from /lib64/libpthread.so.0
  • #9 clone
    from /lib64/libc.so.6 






Comment 1


Milan Crha





          2012-01-24 07:44:25 UTC
        



Downstream bug report from 3.2.3:
https://bugzilla.redhat.com/show_bug.cgi?id=772650

Thread 2 is disposing ldap backend, while Thread 1 is inside poll_ldap with the same backend. There should be a better mechanism to stop poll_ldap in this case.

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




+
Trace
    229507






Thread 6
          (Thread 0x7fbebd6eb700 (LWP 2148))


    

  • 
#0
read

    
                at ../sysdeps/unix/syscall-template.S
                  line
                  82

    

    • 

  • 
#1
read

    
                at /usr/include/bits/unistd.h
                  line
                  45

    

    • 

  • 
#2
unix_signal_helper_thread

    
                at gmain.c
                  line
                  4551

    

    • 

  • 
#3
g_thread_create_proxy

    
                at gthread.c
                  line
                  1962

    

    • 

  • 
#4
start_thread

    
                at pthread_create.c
                  line
                  309

    

    • 

  • 
#5
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  115

    

    • 













Comment 2


Milan Crha





          2012-06-15 14:29:26 UTC
        



I believe this is caused by the same issue as bug #674454, thus I'm marking this as a duplicate of it.

*** This bug has been marked as a duplicate of bug 674454 ***






Comment 3


Milan Crha





          2012-10-16 15:16:49 UTC
        



The same downstream bug report from 3.4.4, which proves this not being a duplicate of bug #674454, but this is a bug on its own, with a description from comment #1:

> Thread 2 is disposing ldap backend, while Thread 1 is inside poll_ldap with
> the same backend. There should be a better mechanism to stop poll_ldap in
> this case.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=860294






Comment 4


Milan Crha





          2012-10-17 11:46:22 UTC
        



Created attachment 226636 [details] [review]
eds patch

for evolution-data-server;

This should make it. The whole body of poll_ldap() is now guarded by the global rec lock, which is used to operate with the ldap handle, and it's also used in the finalize function, thus the ldap handle will not be able to disappear before poll_ldap() is done with it.






Comment 5


Milan Crha





          2012-10-17 11:48:27 UTC
        



Created commit c436d09 in eds master (3.7.1+)
Created commit 49869a0 in eds gnome-3-6 (3.6.2+)