From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: I'm getting a hang at startup with evolution. An strace seems to indicate that its hanging while trying to talk to orbit? I'll include just the seemingly relevant part here. If you need a complete strace, I can provide it. {{{lots of stuff removed}}} open("/etc/localtime", O_RDONLY) = 45 fstat(45, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 fstat(45, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab044f000 read(45, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1267 close(45) = 0 munmap(0x2aaab044f000, 4096) = 0 stat("/usr/share/zoneinfo/UTC", {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 open("/usr/share/zoneinfo/UTC", O_RDONLY) = 45 fstat(45, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 fstat(45, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab044f000 read(45, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0"..., 4096) = 56close(45) = 0 munmap(0x2aaab044f000, 4096) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 open("/etc/localtime", O_RDONLY) = 45 fstat(45, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 fstat(45, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab044f000 read(45, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1267 close(45) = 0 munmap(0x2aaab044f000, 4096) = 0 stat("/usr/share/zoneinfo/UTC", {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 open("/usr/share/zoneinfo/UTC", O_RDONLY) = 45 fstat(45, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 fstat(45, {st_mode=S_IFREG|0644, st_size=56, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab044f000 read(45, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0"..., 4096) = 56close(45) = 0 munmap(0x2aaab044f000, 4096) = 0 futex(0x391feb66d0, FUTEX_WAKE, 2147483647) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 open("/etc/localtime", O_RDONLY) = 45 fstat(45, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 fstat(45, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaab044f000 read(45, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1267 close(45) = 0 munmap(0x2aaab044f000, 4096) = 0 pipe([45, 46]) = 0 pipe([47, 48]) = 0 mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x40, -1, 0) = 0x42804000 mprotect(0x42804000, 4096, PROT_NONE) = 0 clone(child_stack=0x42844270, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0x428449f0, tls=0x42844960, child_tidptr=0x428449f0) = 22789 writev(17, [{"GIOP\1\2\1\0\326\0\0\0", 12}, {"\350R\300\377\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\236F\364"..., 214}], 2) = 226 futex(0x56d234, FUTEX_WAIT, 1, NULL) = 0 futex(0x56d200, FUTEX_WAKE, 1) = 0 writev(17, [{"GIOP\1\2\1\0\346\2\0\0", 12}, {"\330Q\300\377\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\236F\364"..., 742}], 2) = 754 futex(0x56d234, FUTEX_WAIT, 3, NULL) = 0 futex(0x56d230, FUTEX_WAIT, 2, NULL) = 0 futex(0x56d230, FUTEX_WAKE, 1) = 0 futex(0x56d200, FUTEX_WAIT, 2, NULL) = 0 futex(0x56d200, FUTEX_WAKE, 1) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 49 fcntl(49, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 fcntl(49, F_SETFD, FD_CLOEXEC) = 0 connect(49, {sa_family=AF_FILE, path="/tmp/orbit-tjb/linc-58de-0-d5c33f096220"}, 42) = 0 writev(49, [{"GIOP\1\2\1\0h\2\0\0", 12}, {"\210S\300\377\3\0\0\0\0\0\0\0\34\0\0\0\2\0\0\0\377C)\375"..., 616}], 2) = 628 futex(0x56d234, FUTEX_WAIT, 5, NULL) = 0 futex(0x56d200, FUTEX_WAKE, 1) = 0 writev(49, [{"GIOP\1\2\1\0e\0\0\0", 12}, {"HS\300\377\0\0\0\0\0\0\0\0\34\0\0\0\22\0\0\0\367Dz\6 V"..., 101}], 2) = 113 futex(0xa013b4, FUTEX_WAIT, 1, NULL) = 0 futex(0xa0c020, FUTEX_WAKE, 1) = 0 writev(49, [{"GIOP\1\2\1\0`\0\0\0", 12}, {"\210S\300\377\0\0\0\0\0\0\0\0\34\0\0\0\22\0\0\0\367Dz\6"..., 96}], 2) = 108 futex(0xa013b4, FUTEX_WAIT, 1, NULL and it remains hung here. Version-Release number of selected component (if applicable): evolution-2.2.2-5, evolution-data-server-1.2.2-3 How reproducible: Sometimes Steps to Reproduce: 1. for me, if I just start evolution it hangs most of the time. 2. 3. Additional info: This seems to have got progressively worse since installing FC4. At first I didn't have the problem at all (in fact, it never happened with fc4t?) but now it is a constant struggle to read my email. I normally run evolution with a script that first does a --force-shutdown and that has served me well for several years.
Please can you install the debuginfo packages for evolution and evolution-data-server. More information on doing this can be found here: http://fedora.linux.duke.edu/wiki/StackTraces Then please run evolution normally, wait for it to get stuck. Locate the evolution and evolution-data-server processses using ps, and then do a "gdb attach" to each one. Then please to a "t a a bt" in gdb for each one, and attach the resulting backtraces to his bug. This should give an idea what it's waiting for. Alternatively to all of the above, what happens if you kill bonobo-activation-server before launching evolution? Does it help?
Created attachment 115870 [details] backtrace of evolution Here is the requested backtrace. Looks like it's in the free/busy publishing area and evolution-data-server is not yet running. At least I can disable it and get mail reading working again.
Does the reported hang still occur in Fedora Core 6?
The distribution against which this bug was reported is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as INSUFFICIENT_DATA. Setting status to NEEDINFO, and awaiting information from the reporter. Thanks in advance.
Closing as INSUFFICIENT_DATA.