Bug 753736
| Summary: | [abrt] evolution-data-server-3.2.1-2.fc16: __GI_raise: Process /usr/libexec/e-calendar-factory was killed by signal 6 (SIGABRT) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Theodore Lee <theo148> | ||||||||||
| Component: | glibc | Assignee: | Jeff Law <law> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 16 | CC: | fweimer, jakub, law, mbarnes, mcrha, schwab | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | abrt_hash:b3aa26f2cb86b16be9af0620cd51d85a2725c265 | ||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2011-11-16 16:41:36 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: | |||||||||||||
| Bug Depends On: | 739399 | ||||||||||||
| Bug Blocks: | 753737 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Theodore Lee
2011-11-14 10:44:40 UTC
Created attachment 533491 [details]
File: dso_list
Created attachment 533492 [details]
File: backtrace
Created attachment 533493 [details]
File: maps
Thanks for a bug report. The backtrace shows and error:
> free(): invalid pointer
which might be most likely caused by memory corruption.
Do you have any exact steps how to reproduce it, please? Maybe if you run the factory under valgrind, then it'll show where the memory got corrupted. You can run it from console like this:
$ G_SLICE=always-malloc valgrind --num-callers=50 /usr/libexec/e-calendar-factory &>log.txt
only before that make sure no other e-calendar-factory is running, neither evolution itself, and make sure you've installed debug info packages at least for evolution-data-server and evolution.
Then run evolution and try to reproduce the issue. Valgrind can avoid crashes in certain situations, but it writes issues in the log, thus even if the factory doesn't crash, the log can contain the information about the memory issue. Please, upload the resulting log.txt file. Thanks in advance.
*** Bug 753737 has been marked as a duplicate of this bug. *** Hmm... I'm only seeing this crash when I log into GNOME, and even then only intermittently, but I'll see if I can reproduce it. I'm also running versions of various packages (notably glibc) from updates-testing, so that might be related. Created attachment 533728 [details]
Valgrind log
Okay, it looks like I can only reproduce the crash when e-calendar-factory is started while I don't have a network connection up. The log file from running e-calendar-factory under valgrind for a couple of minutes (without a network connection), then terminating it with ^C is now attached.
Thanks for the update. It did catch the issue and logged it: ==3240== Thread 7: ==3240== Invalid free() / delete / delete[] ==3240== at 0x4A0662E: free (vg_replace_malloc.c:366) ==3240== by 0x39721149B7: __free_in6ai (in /lib64/libc-2.14.90.so) ==3240== by 0x39720DC7FD: getaddrinfo (in /lib64/libc-2.14.90.so) ==3240== by 0x39758763AB: ??? (in /lib64/libgio-2.0.so.0.3000.1) ==3240== by 0x39758766C9: ??? (in /lib64/libgio-2.0.so.0.3000.1) ==3240== by 0x397406C6F7: ??? (in /lib64/libglib-2.0.so.0.3000.1) ==3240== by 0x397406A1D5: ??? (in /lib64/libglib-2.0.so.0.3000.1) ==3240== by 0x3972807D8F: start_thread (in /lib64/libpthread-2.14.90.so) ==3240== by 0x39720EF2FC: clone (in /lib64/libc-2.14.90.so) ==3240== Address 0x39723b2390 is 0 bytes inside data symbol "noai6ai_cached" I'm moving this to glibc, where the issue comes from. Just to be sure, what is your currently installed glibc and glib2 version, please? (rpm -q glibc glib2) $ rpm -q glibc glib2 glibc-2.14.90-14.x86_64 glibc-2.14.90-14.i686 glib2-2.30.1-1.fc16.x86_64 glib2-2.30.1-1.fc16.i686 Note that, at the time I reported and reproduced this bug, I was running glibc-2.14.90-16 - I've since downgraded back to the version in stable, and it seems to have gotten rid of this issue (and a few others). *** This bug has been marked as a duplicate of bug 754026 *** |