GNOME Bugzilla – Bug 303067
Random crash looking up addresses in new email
Last modified: 2008-04-15 19:15:19 UTC
Distribution: Fedora Core release 2 (Tettnang) Package: Evolution Severity: normal Version: GNOME2.10.1 unspecified Gnome-Distributor: GARNOME Synopsis: Random crash looking up addresses in new email Bugzilla-Product: Evolution Bugzilla-Component: Miscellaneous Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.10.0) Description: Description of the crash: I'm in the middle of composing an email. I go to any of the address fields, start typing a recipient, and suddenly I get a dialog saying evolution-exchange-storage has crashed. How often does this happen? It's random. Once or twice a day. Additional Information: Evolution 2.3.1, GARNOME/GNOME 2.10.1, Fedora Core 2. Debugging Information: Backtrace was generated from '/home/garnome/2.10.1/libexec/evolution-exchange-storage' ------- Bug moved to this database by unknown@bugzilla.gnome.org 2005-05-04 22:23 UTC -------
I guess bug buddy didn't really generate a stack trace. Because I've seen this before, I had evolution-exchange-storage attached to gdb. However, when the crash happened, gdb didn't stop... so before I filled out the bug report, while evolution was hung, I Ctrl-c in gdb and got a stack trace then: Program received signal SIGINT, Interrupt. [Switching to Thread -1222265760 (LWP 26324)] 0x443047a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) thread apply all bt
+ Trace 59182
Thread 179 (Thread -1282409552 (LWP 28409))
Then I did a continue in gdb, which allowed me to use bug buddy. After bug buddy was done, gdb stopped the process, so I did another thread dump just in case, this one slightly different: (gdb) cont Continuing. Program received signal SIGCONT, Continued. 0x443047a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) thread apply all bt
+ Trace 59183
The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /home/garnome/2.10.1/libexec/evolution/2.4/evolution-exchange-storage, process 26324
Thanks for those stacktraces. These appear to be unique (not reported before). Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
I've recompiled evolution-exchange-storage with -g but I still get similar stack traces. What symbols exactly do you want me to use? The "Getting Traces" article didn't say much useful. Here's a sample compile command while it was building... note -g and -O2 (not -O3): cc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"evolution-exchange-storage\" -DORBIT2=1 -pthread -I/home/garnome/2.10.1/include/evolution-2.4 -I/home/garnome/2.10.1/include/libgnome-2.0 -I/home/garnome/2.10.1/include/libgnomeui-2.0 -I/home/garnome/2.10.1/include/libbonoboui-2.0 -I/home/garnome/2.10.1/include/gal-2.6 -I/home/garnome/2.10.1/include/glib-2.0 -I/home/garnome/2.10.1/lib/glib-2.0/include -I/home/garnome/2.10.1/include/orbit-2.0 -I/home/garnome/2.10.1/include/libbonobo-2.0 -I/home/garnome/2.10.1/include/gconf/2 -I/home/garnome/2.10.1/include/gnome-vfs-2.0 -I/home/garnome/2.10.1/lib/gnome-vfs-2.0/include -I/home/garnome/2.10.1/include/bonobo-activation-2.0 -I/home/garnome/2.10.1/include/libgnomecanvas-2.0 -I/home/garnome/2.10.1/include/gtk-2.0 -I/home/garnome/2.10.1/include/libart-2.0 -I/home/garnome/2.10.1/include/pango-1.0 -I/usr/include/freetype2 -I/home/garnome/2.10.1/lib/gtk-2.0/include -I/home/garnome/2.10.1/include/atk-1.0 -I/usr/X11R6/include -I/usr/include/freetype2/config -I/home/garnome/2.10.1/include/libxml2 -I/home/garnome/2.10.1/include/libglade-2.0 -I/home/garnome/2.10.1/include/libgnomeprint-2.2 -I/home/garnome/2.10.1/include/evolution-data-server-1.4 -I/home/garnome/2.10.1/include/libsoup-2.2 -I/usr/include -I/opt/openldap-ntlm-2.2.24/include -DPREFIX=\"/home/garnome/2.10.1\" -DSYSCONFDIR=\""/home/garnome/2.10.1/etc"\" -DDATADIR=\""/home/garnome/2.10.1/share"\" -DLIBDIR=\""/home/garnome/2.10.1/share"\" -DCONNECTOR_GLADEDIR=\""/home/garnome/2.10.1/share/evolution-exchange/2.4/glade"\" -DCONNECTOR_IMAGESDIR=\""/home/garnome/2.10.1/share/evolution-exchange/2.4/images"\" -DCONNECTOR_UIDIR=\""/home/garnome/2.10.1/share/evolution-exchange/2.4/ui"\" -DCONNECTOR_LOCALEDIR=\""/home/garnome/2.10.1/share/locale\"" -I.. -I../lib -I../xntlm -I../mail -I../shell -I../camel -I../calendar -I../shell -I../lib -I/home/garnome/2.10.1/include -g -I/home/garnome/2.10.1/include -L/home/garnome/2.10.1/lib -O2 -pipe -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Wno-sign-compare -c `test -f 'exchange-offline-listener.c' || echo './'`exchange-offline-listener.c
All lines should look like the following:
+ Trace 59249
Eg.. stuff between the (). I think gargnome strips the debugging symbols. That should be disabled (not sure how with gargnome).
*** Bug 304783 has been marked as a duplicate of this bug. ***
Raul: You need to recompile the dependent libraries in addition to evolution-exchange-storage. That would include evolution-data-server and ORBit2. Bug 304783 has debugging symbols for evolution-data-server (but not for ORBit2). That may be enough additional information, so I'll reopen so that a maintainer can look...
connector right? m oving component.
Can you please verify this with 2.4.1. There was a mutex lock added in GAL handling of exchange to solve this. Please get the traces for all the exchange threads if you still see this.
Please re-open the bug if you are still seeing this issue.
Reopening, I see weak points in an ldap addressbook backend, in these functions, which should be fixed to have this fixed properly. First thing is every use of priv->ldap should be guarded with eds_ldap_handler_lock, but in ..._search function it isn't. And in other functions too. The second thing I believe is also wrong is the logic of this construction: ldap = priv->ldap; do { lock(); xxx (ldap, ...); unlock(); } while (e_book_backend_ldap_reconnect (...)); it's in pseudo code only, but my point is that the e_book_backend_ldap_reconnect *can* change priv->ldap, thus next use of local variable ldap will do a crash or unexpected behavior. Does it make sense?
Created attachment 106642 [details] [review] proposed eds patch for evolution-data-server; patch fixing things in a way described in previous comment.
Created attachment 106647 [details] [review] proposed eex patch for evolution-exchange; Please notice this chunk: @@ -1459,8 +1470,8 @@ build_contact_from_entry (EBookBackendGA I changed 'ldap' to 'subldap'. I believe it's the right thing.
Regarding the eds patch, why is the lock global when there can be multiple backend instances?
Good question. I have no idea, I kept it as it was. If you feel it should be changed, then I've nothing against it.
If the lock can be per-instance then it should, otherwise you are blocking all instances.
Created attachment 106703 [details] [review] proposed eds patch ][ for evolution-data-server; Updated based on the Ross' comments above. Thanks Ross. To be honest, I should do that in the first patch, god knows why I didn't.
Oh, it turns out that libldap is tragically thread unsafe, so the lock is really to guard libldap access.
Hehe :) Thanks for the review Ross.
2.22.1 & 2.23.1
eds part committed to trunk. Committed revision 8572. eds part committed to gnome-2-22. Committed revision 8573. eex part is waiting for a review :)
Milan, commit it to stable/trunk.
eex committed to trunk. Committed revision 1617. eex committed to gnome-2-22. Committed revision 1618.
*** Bug 526828 has been marked as a duplicate of this bug. ***
*** Bug 528233 has been marked as a duplicate of this bug. ***