GNOME Bugzilla – Bug 632669
Crash when path for attachments doesn't exist
Last modified: 2010-11-10 17:10:48 UTC
Created attachment 172823 [details] exchange calendar error Hi, I have the following error when I try to connect to exchange calender with the new evolution release (with evolution 2.30 I didn't see any errors) Oct 20 11:13:52 localhost kernel: e-calendar-fact[27866]: segfault at 0 ip 00007f0bd5bee712 sp 00007f0bbfffebf8 error 4 in libc-2.12.1.so[7f0bd5b73000+153000] my environment: evolution = 2.32 evolution-exchange = 2.32 Linux distribution = archlinux Exchange 2003 server Thanks
When evolution-data-server crashes, above error message pops up. Please try to collect trace of evolution-data-server. You can start evolution-data-server in separate terminal under gdb and then start evolution. When it will crash, you can paste the traces here and make sure you have debuginfo packages installed. see http://live.gnome.org/GettingTraces/Details#gdb-not-yet-running and http://live.gnome.org/GettingTraces/DistroSpecificInstructions for details about how to do this
Created attachment 172837 [details] gdb output
Hi Akhil, Please find attached the gdb output from /usr/lib/evolution-data-server-1.2/e-calendar-factory.
When application SIGSEGV in gdb, you will have to do 'thread apply all bt' and then paste the traces here.
Created attachment 172906 [details] the output from "thread apply all bt"
I attached a new txt file containing the out from "thread apply all bt"
can be a duplicate of bug 508447 Can you please install debuginfo packages of evolution-data-server, evolution-exchange and glib2 and provide better traces.
Because I use Archlinux I don't have a debuginfo package. I will recompile these three packages with debugging enabled and binary stripping disabled also.
Created attachment 172923 [details] debugging enabled and without stripping
Hi Akhil, I uploaded a new gdb output. I hope that this one would be more helpful.
Hi, this is a very outstanding issue, as Akhil pointer out on IRC, a bug #508447, which is resisting from a proper fix due to lack of reproducibility. I would like to ask you for a bit more debugging here, specifically for a 'body' value from > #3 0x00007fffe6d9723c in add_ical (cbex=0x646c20, href=0x6fdd80, > lastmod=0x6e0540, uid=0x6e05d0, body=<value optimized out>, > len=<value optimized out>, receipts=0) > at e-cal-backend-exchange-calendar.c:279 as stated in the crashing thread below. The problem is that the "<value optimized out>", so if you would be able to compile evolution-exchange with -O0 to disable optimizations there, then it'll fix this thing. After that it may be enough to guide gdb (now stopped in the crash) to frame 3 and get the value of the 'body' variable, like this: $(gdb) f 3 $(gdb) printf "%s\n", body Note that the value will contain quite many private information, like names, email addresses, maybe URLs, and the most some attachment(s), which I'm not interested in at all (the content, not tags around), thus these can be safely removed. I would be happy to guide you though this all if you are not sure, just find me on IRC server irc.gimp.org on the #evolution channel.
+ Trace 224260
Thread 7 (Thread 0x7fffe4f52710 (LWP 11982))
Hi Milan, Right now I can't connect to IRC channel. I already recompiled the evolution-exchange with -O0 optimization option and I encounter the same problem. Are you so kind to let me know when should I give the "f 3" gdb command ? after "thread apply all bt" ? or right after "run" ?
after run, when gdb stops on the crash.
Created attachment 172930 [details] the out from f 3 & printf "%s\n", body Please find attached the body output, without the base64 attachments
great, thanks a lot, this is what I was looking for. I'll give it a try soon.
interesting is that i hadn't any problems with evolution 2.28.x and 2.30.x (i don't recall to have any problems with 2.26.1 or 2.26.2 also)
Hi Milan, do you have any news ?
Unfortunately not, I'm sorry. My exchange server is down at the moment, and because I cannot influence when it'll be turned on again, then I'm just waiting until someone processes my request. I'll let you know when I have any update. (I have this bug opened, to not forget of it.)
Hi Milan, any chance to solve this issue this week ?
There is one possibility, open the event in Outlook and save it. The last time I tried this with other user it begun to work properly in evolution. I've no idea what the Outlook did with the event, but it fixed it. Unfortunately for evolution we wasn't able to verify any fix. (And my server is still down) :( You can find the OWA url in your backtrace, so login to Outlook Web Interface and paste the URL.
Hi, I tried to open and save the event with Outlook and I still have the same issue. I also deleted the event and nothing new. I didn't experienced this issue with evolution 2.28.x and 2.30.x and i think also with 2.26.x. Unfortunately I cannot use evolution 2.32 as a MS Exchange client. Until this issue will be fixed I switched to thunderbird + davmail . Thanks, -- cosmih
Downstream bug report about the same: https://bugzilla.redhat.com/show_bug.cgi?id=649198
I can reproduce it finally, on a new machine. Basically, the path it tries to save the attachment is not accessible, and thus the saving fails, which is not checked later, and a bit more later factory crashes. You can workaround this by invoking a command: $ mkdir ~/.cache/evolution/calendar before running evolution.
Created attachment 173903 [details] [review] eex patch for evolution-exchange; I tried to search the code base and it seems fine there, but in eex calendar, where is created a symlink, and which expects to have the $CACHE/calendar created already. This patch fixes the issue by creating this folder when the symlink-ing fails, and prevents further crashes, which are now replaced by simple warning on the e-calendar-console.
Created commit 94728ba in eex master (2.91.2+) Created commit cbc06d6 in eex gnome-2-32 (2.32.1+)
Any Ideas if this fix will be ported into Fedora14? Is it possible for me to build this myself?
(In reply to comment #26) > Any Ideas if this fix will be ported into Fedora14? Yes, it'll be part of 2.32.1 update some time next week, but you can try the workaround from comment #23.
Yep the workaround works! Thanks so much!
1) the workaround works, meaning i can see the old calendar objects 2) i applied the patch and also works, meaning i can see the old calendar objects but now i have a different issue: - all new meeting requests are seen as a regular messages, meaning when I open the meeting request I don't have anymore the options to save/accept/reject the request. it is just a regular message. - also the "Message -> Create a Meeting" menu is not working, meaning that is not creating the meeting but I don't see any errors.
(In reply to comment #29) > but now i have a different issue: Call me a stranger or however you would like, but when you confirm that the fix for this bug is working as expected, why are you reopening this and telling that you have a *different* issue? If it's a different thing, then open a new bug report or, even better, try to search for it and if you do not find any matching your issue then open a new bug report. Would you imagine having all issues listed in one bug report? I really do not. > - all new meeting requests are seen as a regular messages, meaning when I open > the meeting request I don't have anymore the options to save/accept/reject the > request. it is just a regular message. That's bug #630518, most likely, and maybe few consecutive. Fixed in 2.32.1. > - also the "Message -> Create a Meeting" menu is not working, meaning that is > not creating the meeting but I don't see any errors. I think I saw something similar, possibly filled already, though I cannot find it now. When I try this with the code which will become a 2.32.1 then I'm asked for a destination - so it does something. Make sure there is some message selected. Please create a new bug report for this.
Ok, sorry and thanks.