Bug 384741
| Summary: | crash on startup (possibly related to gssapi imap?) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeremy Katz <katzj> |
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | mcrha |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-11-15 17:53:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jeremy Katz
2007-11-15 15:12:07 UTC
Can you install evolution-data-server-debuginfo and post that again? #0 0x0012d402 in __kernel_vsyscall ()
#1 0x003fd119 in __lll_lock_wait () from /lib/libpthread.so.0
#2 0x003f889e in _L_lock_88 () from /lib/libpthread.so.0
#3 0x003f83aa in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0x0805de51 in ?? ()
#5 <signal handler called>
#6 0x02d268a5 in memcpy () from /lib/libc.so.6
#7 0x019377ca in g_array_append_vals () from /lib/libglib-2.0.so.0
#8 0x01937830 in g_byte_array_append () from /lib/libglib-2.0.so.0
#9 0x00326df6 in camel_sasl_challenge_base64 (sasl=0xb510cbd0,
token=0xb24a52ea "", ex=0x9b64444) at camel-sasl.c:143
#10 0x014c7d9d in try_auth (store=0x99035a8, mech=0x33f0f5 "GSSAPI",
ex=0x9b64444) at camel-imap-store.c:1273
#11 0x014ca18f in imap_connect_online (service=0x99035a8, ex=0x9b64444)
at camel-imap-store.c:1353
#12 0x00309136 in disco_connect (service=0x99035a8, ex=0x9b64444)
at camel-disco-store.c:162
#13 0x0032924f in camel_service_connect (service=0x99035a8, ex=0x9b64444)
at camel-service.c:371
#14 0x014c450c in camel_imap_store_connected (store=0x99035a8, ex=0x9b64444)
at camel-imap-store.c:2989
#15 0x014bff81 in imap_refresh_info (folder=0x9b665fc, ex=0x9b64444)
at camel-imap-folder.c:522
#16 0x00307ac6 in disco_refresh_info (folder=0x9b665fc, ex=0x9b64444)
at camel-disco-folder.c:269
#17 0x00318dee in camel_folder_refresh_info (folder=0x9b665fc, ex=0x9b64444)
at camel-folder.c:302
#18 0x04c79237 in ?? ()
from /usr/lib/evolution/2.22/components/libevolution-mail.so
#19 0x04c76969 in ?? ()
from /usr/lib/evolution/2.22/components/libevolution-mail.so
#20 0x0197a1d8 in ?? () from /lib/libglib-2.0.so.0
#21 0x0197864f in ?? () from /lib/libglib-2.0.so.0
#22 0x003f650b in start_thread () from /lib/libpthread.so.0
#23 0x02d88b2e in clone () from /lib/libc.so.6
Thanks, that helps. If you get time, can you provide another backtrace with glib2-debuginfo installed? Meanwhile I think I have enough here to start looking into it. Looks like maybe the Base64 decoding failed and we're trying to append bogus data (or a bogus length) to the GByteArray. Thread 3 (Thread 0xb50fbb90 (LWP 20423)):
#0 0x0012d402 in __kernel_vsyscall ()
#1 0x003fd119 in __lll_lock_wait () from /lib/libpthread.so.0
#2 0x003f889e in _L_lock_88 () from /lib/libpthread.so.0
#3 0x003f83aa in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0x0805de51 in ?? ()
#5 <signal handler called>
#6 0x05eee8a5 in memcpy () from /lib/libc.so.6
#7 0x04c1d7ca in IA__g_array_append_vals (farray=0x9929880, data=0x0,
len=3304859) at /usr/include/bits/string3.h:52
#8 0x04c1d830 in IA__g_byte_array_append (array=0x9929880, data=0x0,
len=3304859) at garray.c:653
#9 0x00326df6 in camel_sasl_challenge_base64 (sasl=0x94c1410,
token=0x961149a "", ex=0x960d244) at camel-sasl.c:143
#10 0x058eed9d in try_auth (store=0x94b4be0, mech=0x33f0f5 "GSSAPI",
ex=0x960d244) at camel-imap-store.c:1273
#11 0x058f118f in imap_connect_online (service=0x94b4be0, ex=0x960d244)
at camel-imap-store.c:1353
#12 0x00309136 in disco_connect (service=0x94b4be0, ex=0x960d244)
at camel-disco-store.c:162
#13 0x0032924f in camel_service_connect (service=0x94b4be0, ex=0x960d244)
at camel-service.c:371
#14 0x00308f08 in set_status (disco_store=0x94b4be0,
status=CAMEL_DISCO_STORE_ONLINE, ex=0x960d244) at camel-disco-store.c:343
#15 0x003087bd in camel_disco_store_set_status (store=0x94b4be0,
status=CAMEL_DISCO_STORE_ONLINE, ex=0x960d244) at camel-disco-store.c:362
#16 0x06aaa031 in ?? ()
from /usr/lib/evolution/2.22/components/libevolution-mail.so
#17 0x06aa8969 in ?? ()
from /usr/lib/evolution/2.22/components/libevolution-mail.so
#18 0x04c601d8 in g_thread_pool_thread_proxy (data=0x94b45d8)
at gthreadpool.c:265
#19 0x04c5e64f in g_thread_create_proxy (data=0x9925008) at gthread.c:635
#20 0x003f650b in start_thread () from /lib/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#21 0x05f50b2e in clone () from /lib/libc.so.6
Here's the offending code:
if (token) {
guchar *data;
gsize length;
data = g_base64_decode (token, &length);
token_binary = g_byte_array_new ();
g_byte_array_append (token_binary, data, length);
g_free (data);
} else
token_binary = NULL;
Frame #9 shows 'token' is an empty string, which is not valid Base64. So
g_base64_decode() fails and returns NULL but 'length' is left uninitialized.
The bogus 'length' value is passed to g_byte_array_append() and causes the crash.
So two things:
1) Change the 'if' expression to (token && *token).
2) Initialize 'length' to zero, just to be pedantic.
Moving this upstream with a patch. See [1] for further updates. [1] http://bugzilla.gnome.org/show_bug.cgi?id=474000 Patch was committed upstream. I've added it to evolution-data-server-2.21.2-2.fc9 in the meantime. |