| Summary: | [abrt] evolution-data-server-3.0.1-1.fc15: emsmdb_transaction: Process /usr/libexec/e-addressbook-factory was killed by signal 11 (SIGSEGV) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christoph Maser <christoph.maser> | ||||||
| Component: | evolution-mapi | Assignee: | Matthew Barnes <mbarnes> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 15 | CC: | mbarnes, mcrha | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | abrt_hash:e7919356880c8820be0b14fc2185b5ae8bebe7f6 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-06-10 05:36:22 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
Christoph Maser
2011-06-01 15:01:31 UTC
Created attachment 502296 [details]
File: maps
Created attachment 502297 [details]
File: backtrace
Thanks for a bug report. I see it crashed when a new connection was about to establish towards your exchange server. Is it possible that this crash happened after a longer time period of the e-addressbook-factory running? I guess the emsmdb_ctx=0x0 is a reason for the crash, and I'm wondering whether it was because of low memory or failed connection towards the server. If you can run the factory from a console and see its output before the crash, then it'll may give us a bit more details what was going wrong.
You can do that by these steps:
a) close evolution and make sure no other e-addressbook-factory process
is running
b) open a terminal and run the factory like this:
$ /usr/libexec/e-addressbook-factory &>log.txt
c) then wait few seconds (5 is usually fine, it's time the factory requires
to initialize its internal structures) and run evolution from another
console.
d) then use it like you usually do, and if it'll crash, then examine
the resulting log.txt file for its output.
Thread 1 (Thread 0x7f84bb7fe700 (LWP 6507)):
#0 emsmdb_transaction (emsmdb_ctx=0x0, mem_ctx=0x7f84c42d57d0, req=0x7f84c475dad0, repl=0x7f84bb7fdc20) at libmapi/emsmdb.c:307
r = {in = {mapi_request = 0x54, max_data = 0, handle = 0x4, size = 84, offset = 0, length = 0x7f84c4767b00}, out = {mapi_response = 0x311607c925, handle = 0x53, size = 3291305936, offset = 32644, length = 0x7f84e06832d8, result = MAPI_E_SUCCESS}}
mapi_response = <optimized out>
length = <optimized out>
status = <optimized out>
multi_req = <optimized out>
i = 0 '\000'
#1 0x00007f84e05e5a25 in OpenUserMailbox (session=0x7f84c473bd70, username=0x0, obj_store=0x7f84b000d070) at libmapi/IMAPISession.c:373
mapi_request = 0x7f84c475dad0
mapi_response = 0x7f84c4000020
mapi_req = 0x7f84c4767b00
request = {LogonFlags = 1 '\001', OpenFlags = 1036, StoreState = 0, EssDN = <optimized out>}
status = <optimized out>
retval = <optimized out>
size = <optimized out>
mem_ctx = 0x7f84c42d57d0
store = <optimized out>
mailbox = 0x7f84c475b7f0 "/o=WEBDE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=cmaser"
logon_id = 1 '\001'
retry = false
#2 0x00007f84e08ff75d in exchange_mapi_connection_new (profile=0x7f84b4009f10 "cmaser@<optimized out>@<optimized out>", password=<optimized out>, perror=0x7f84bb7fdce8) at exchange-mapi-connection.c:386
conn = 0x7f84b000d000
priv = 0x7f84b000d020
session = 0x7f84c473bd70
ms = <optimized out>
__PRETTY_FUNCTION__ = "exchange_mapi_connection_new"
I could not reproduce the issue until now. Since 3.0.2 was installed shortly after I reported I suspect it might have been fixed in that release... Thanks for the update. To be honest, this kind of crash is usually rather occasional, which happens from time to time, but which is never able to reproduce on will. I hope the updated openchange in F16 will behave better, as F15 has still openchange 0.9, which is quite old. I'm closing this for now, but please feel free to reopen. |