| Summary: | [abrt] evolution-data-server-3.0.2-1.fc15: _int_realloc: Process /usr/libexec/e-addressbook-factory was killed by signal 11 (SIGSEGV) | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Boricua <ortizsantini> | ||||||||||||
| Component: | evolution-data-server | Assignee: | Matthew Barnes <mbarnes> | ||||||||||||
| Status: | CLOSED UPSTREAM | 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:0b2b2a7dc17dbede4ba5563629724d44b014bbc0 | ||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2011-06-30 12:00:37 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
Boricua
2011-06-19 08:24:48 UTC
Created attachment 505429 [details]
File: maps
Created attachment 505430 [details]
File: backtrace
Thanks for a bug report. The backtrace suggests that the e-addressbook-factory process was out of memory, but because ABRT cannot capture .xsession-errors then I cannot tell for sure. Could you run e-addressbook-factory under valgrind for some time and post the captured log here, to see what was leaking for you, please? You can do that by these steps:
a) close evolution
b) make sure e-addressbook-factory is not running, can be also done by:
$ evolution --force-shutdown
c) open a terminal and run the factory there, like this:
$ G_SLICE=always-malloc valgrind --num-callers=50 --leak-check=full \
/usr/libexec/e-addressbook-factory &>log.txt
d) then run evolution itself, and use it for some time as before
e) after some time, say 10-30 minutes, an hour or at the end of day (the more
the better), close the evolution and wait whether the factory will close
itself too - it may in about 10 seconds after evolution is closed and
nothing else is using it. If it will not be closed automatically, then press
Ctrl+C once in the terminal where you run it under valgrind. Then it'll
create the leak report, which can take some time (note of higher CPU usage).
The log.txt file may contain memory leak information and leak summary
at the end of file. Please upload the file here, for an investigation.
Thanks in advance.
Hi Milan. I started evolution as requested and hope to have something for the afternoon. Just in case, I must warn that this machine is already running under stress, even with 4gb of memory, due to an unresolved issue regarding nouveau/nvidia drivers with the Geforce 7300 graphics card. Hi. I'm sorry for the delay. Had a serious crash that ended in a new graphics card and new F15 installation. The crash was caused by problems with my nvidia geforce 7300 card and might have something to do with evolution's crash. Nevertheless I finally ran the test and will upload 3 logs, being log.txt the longest. Hope it helps. Created attachment 510461 [details]
Longest log
Created attachment 510462 [details]
Short log
Created attachment 510463 [details]
Medium log
Thanks for the update. The short log, same as the medium log, is pretty clean, it has no definitely lost memory. The longest log shows some definitely lost memory, mostly related to google backend/account, but still, it may not result in a low memory for the process: > LEAK SUMMARY: > definitely lost: 88 bytes in 17 blocks > indirectly lost: 192 bytes in 1 blocks > possibly lost: 10,524 bytes in 194 blocks > still reachable: 1,614,257 bytes in 7,707 blocks On the other hand, having e-addressbook-factory running for a longer time, with some extensive using of a google backend, I believe it can get out of memory too. There are also interesting these runtime warnings: > ...libebookbackendgoogle-WARNING **: Connection to Google already established. > ...g_object_unref: assertion `G_IS_OBJECT (object)' failed > ...g_object_unref: assertion `G_IS_OBJECT (object)' failed > > ...libebookbackendgoogle-WARNING **: Connection to Google already established. > ...g_object_unref: assertion `G_IS_OBJECT (object)' failed > ...g_object_unref: assertion `G_IS_OBJECT (object)' failed I moved this upstream as [1]. Please see [1] for any further updates. If possible, please CC yourself there, in case upstream developers will have additional questions. [1] https://bugzilla.gnome.org/show_bug.cgi?id=653736 Ok, w'll do. Thanks for the info. |