| Summary: | [abrt] evolution-data-server: e_soap_response_from_xmldoc(): evolution-calendar-factory-subprocess killed by SIGSEGV | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Krzysztof Troska <elleander86> | ||||||||||||||||||||||||||||
| Component: | evolution-data-server | Assignee: | Milan Crha <mcrha> | ||||||||||||||||||||||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||||
| Version: | 24 | CC: | mbarnes, mcrha | ||||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/31f329c835293c9799b3f13f569602cd81b2a356 | ||||||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:ef81c66ee8a09e6929063b534cfca1bf34f53672;VARIANT_ID=workstation; | ||||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||||
| Last Closed: | 2016-10-06 10:36:46 UTC | Type: | --- | ||||||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||
|
Description
Krzysztof Troska
2016-09-29 07:04:55 UTC
Created attachment 1205819 [details]
File: backtrace
Created attachment 1205820 [details]
File: cgroup
Created attachment 1205821 [details]
File: core_backtrace
Created attachment 1205822 [details]
File: dso_list
Created attachment 1205823 [details]
File: environ
Created attachment 1205824 [details]
File: exploitable
Created attachment 1205825 [details]
File: limits
Created attachment 1205826 [details]
File: maps
Created attachment 1205827 [details]
File: mountinfo
Created attachment 1205828 [details]
File: namespaces
Created attachment 1205829 [details]
File: open_fds
Created attachment 1205830 [details]
File: proc_pid_status
Created attachment 1205831 [details]
File: var_log_messages
Thanks for a bug report. I see ABRT found a possible already filled bug #1215317, which looks very similar. The problem with it is that the bug report has no real resolution. I see from the backtrace that this crashed in the calendar factory when serving one of your evolution-ews calendars, but nothing more. If you'd have any insight, any detail about what was happening with the machine, the connection, or any other detail, then it'll be helpful. I do not recall seeing this myself in the past, though my EWS account doesn't have much activity. Nope sorry no idea, I was trying to brake it but it just won't brake in a way i can reproduce. It just randomly pop up in my problem reporting and lately I don't even have this. My only idea is that office 365 (which my company use for EWS accounts) is returning some weird data. And yes it happens sometimes that i go the web based client and it shows random errors, maybe not enough sanity check in soap responses? Thanks for the update. It looks to me like some sort of use-after-free, because the related code is this:
229 if (xml_body != NULL) {
230 if (strcmp ((const gchar *) xml_body->name, "Header") == 0) {
231 /* read header parameters */
232 parse_parameters (response, xml_body);
233 xml_body = soup_xml_real_node (xml_body->next);
234 }
where the place of the crash is line 233, which dereferences xml_body (by accessing its xml_body->next member). The backtrace shows that the xml_body is NULL, thus, if the gdb is correct, then the crash doesn't make sense, because one can get on line 233 only if the xml_body isn't NULL, which is tested on line 229, thus, from my point of view, something wrote somewhere where it shouldn't and it stroke back here. Such issue can strike in (semi-)random places, depending on the actual memory content.
The tools like valgrind can help to identify such issues, but their side effect is also significantly slower run (due to all the memory checking), thus also a change in timing, which can prevent issues which depend on "proper timing".
I'm closing this for now, but feel free to update here, if you find anything interesting, or simply ask in case you'd like to help with something (no need to reopen the bug report, I receive notifications for closed bugs too).
|