| Summary: | Evolution ignores the "Group by thread" setting | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Volans <volans2000> | ||||||||
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 17 | CC: | lucilanga, mbarnes, mcrha, rstrode | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-08-01 03:39:39 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
Volans
2012-02-10 00:05:31 UTC
Thanks for a bug report. I'm not sure which grouping you mean. I tried the View->Group by thread, and it works for me as expected, when it's checked then the messages are grouped by thread, when it's unchecked, then they are not. Could you clarify it, please? Hello, Yes, it's that feature, just that in Portuguese it's "Tree". Anyway, changing that checkbox produces no effect on my Evolution. The messages are always kept organized by thread (subject). Thanks for the update. I do not see any issue in the code on the first look, and if I run evolution in English locale, like this: $ LANG=en_US.utf8 evolution then it works as expected. Though I do not think it has anything to do with other localization. Could you run evolution from console, reproduce the issue, and see whether there are any runtime warnings being shown on the console, please? Maybe there will be shown what's going wrong. If the above will not explain the issue, could you install debuginfo package for evolution, and run it under gdb (install it too, if you do not have it installed) like this: $ gdb evolution --ex "b message_list_set_threaded" --ex r --ex c --ex c It'll ask you whether you want to make the breakpoint as a pending, where you might answer "y". When gdb stops, just do "bt" and then "c" commands in it. It may stop always the function is called. It stops there twice for me on start (that's why I "c" twice in the command already), then twice for each Ctrl+T I press. The "bt" is a command to show backtrace where the call happened, the "c" stands for "continue". When you quit evolution then do just "q" in the gdb prompt to quit it as well. I would like to see from where it is called for you, thus the output from the first "bt" call, down to the "q" execution. It may not expose any private information, but to be sure, please check in the output for passwords or such (I usually search for "pass", which may give you 0 results). Created attachment 572103 [details]
A picture is worth 1000 words....
Created attachment 572106 [details]
A copy-paste log of the gdb command you asked me to do.
I got no errors from running evolution from the console. Using the gdb command (after installing the debug-info) returned the text you can read on this file.
Note:
- 'O daemon D-BUS não se encontra em execução' means "The D-BUS daemon is not running".
- 'A ligação está fechada' means "The connection is closed"
Thanks for the update. So it has trouble with DBus on your machine, connecting to GConf DBus daemon. It seems to me like bug #756245, which is basically about the same. There is a pending update for that bug report, could you try to install it, restart your machine, and see whether it'll help for you, please? Hello, I updated my computer today (and restarted it, of course) and I still have the same problem. Also, tried the gdb command and I get the same output: DBus isn't running. :) I'll attach a new log. Created attachment 572868 [details]
A copy-paste log of the gdb command, after today's update.
Thanks for the update. What is returned when you invoke: $ rpm -q GConf2 please? I'm wondering whether the update is available in fedora-updates, I guess it's in updates-testing only. The patched version is GConf2-3.2.3-4.fc16. Also, from bug #756245 comment #45, could you check whether gconfd-2 is running on your system, and if it does, then kill it and run evolution again, please? I do not know what this is about, but it surely seems like an issue with GConf2 itself. You can check for running gconfd-2 with command like this: $ ps ax | grep gconfd-2 which will also give you the process ID, and simple $ kill PID will restart the daemon (it will close the old one and run new, with new PID). It may help temporarily, based on that comment. Hello again, The result from the 'rpm -q GConf2' command is 'GConf2-3.2.3-1.fc16.x86_64'. Since the patched version is GConf2-3.2.3-4.fc16, I assume it wasn't installed yet in my system... OK, I did a small "experiment". I activated the Fedora test updates repository temporarily and updated just GConf. Now your patch is installed. The 'rpm -q GConf2' command, now returns 'GConf2-3.2.3-4.fc16.x86_64'. However, when I do the command 'gdb evolution --ex "b message_list_set_threaded" --ex r --ex c --ex c', I still get the same result. DBus isn't running. The 'ps ax | grep gconfd-2' command returns two process ID's: 1418 ? S 0:00 /usr/libexec/gconfd-2 2277 pts/2 S+ 0:00 grep --color=auto gconfd-2 When I make kill 1418, like you said, another process is started (with a different ID): 2286 ? S 0:00 /usr/libexec/gconfd-2 2295 pts/2 S+ 0:00 grep --color=auto gconfd-2 Each time I do 'ps ax | grep gconfd-2', I get the almost the same output, except, the second PID is added with 2 units (2297, 2299, 2301,...) Still same symptoms... Thanks for trying that out. I appreciate it. I'm CC'ing maintainer of GConf, because I do not have any other idea apart of that what we tried till now. halfline, do you have any idea why Volans should be receiving "The D-BUS daemon is not running" when running evolution in F16, please? We also tried more things, see above, among them also package from bug #756245, but it didn't help, unfortunately. This bug is still active in version 3.4.3 Do you still receive errors about D-BUS daemon not running, even in Fedora 17? It works fine here, as far as I can tell. I did the 'gdb evolution --ex "b message_list_set_threaded" --ex r --ex c --ex c' command again and it says "The connection is closed". The computer and hardware is the same. I formatted it weeks ago and installed Fedora 17. Noticed the problem was still there. I tried this: $ ps ax | grep gconfd 14162 ? S 0:00 /usr/libexec/gconfd-2 and then also $ gconftool-2 -p which exits immediately with no error message (I suppose it'll report error if it cannot contact the daemon). Then even: $ gconftool-2 --spawn may make sure the daemon is running. If you have it running and you still receive connection errors, then, please, install debuginfo package for GConf2 and get a backtrace of running gconfd-2 with command like this: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt where PID is a process ID of running gconfd-2. Maybe it's stuck in the main thread, thus it cannot respond? The update in that bug didn't fully work. It only reduced the problem. I haven't investigated why yet. OK, here it goes: ------------------------------------------------------ [root@unknownbcaec5a32b66 Volans]# ps ax | grep gconfd 977 ? S 0:00 /usr/libexec/gconfd-2 3070 pts/0 S+ 0:00 grep --color=auto gconfd ------------------------------------------------------ [root@unknownbcaec5a32b66 Volans]# gconftool-2 -p (gconftool-2:3114): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ------------------------------------------------------ [root@unknownbcaec5a32b66 Volans]# gconftool-2 --spawn (gconftool-2:3144): GConf-WARNING **: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Falha ao efectuar "spawn" do servidor de configuração (gconfd): O daemon D-BUS não se encontra em execução ------------------------------------------------------ In my case, D-Bus is process ID 823 (according to system monitor) and it shows as running. [root@unknownbcaec5a32b66 Volans]# gdb --batch --ex "t a a bt" -pid=823 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fcb7c6b3700 (LWP 824)] 0x00000032f6ee8ecf in poll () from /lib64/libc.so.6 Thread 2 (Thread 0x7fcb7c6b3700 (LWP 824)): #0 0x00000032f6ee8ecf in poll () from /lib64/libc.so.6 #1 0x00000032f8610ad6 in ?? () from /lib64/libselinux.so.1 #2 0x00000032f8610ef6 in avc_netlink_loop () from /lib64/libselinux.so.1 #3 0x00000032f7207d14 in start_thread () from /lib64/libpthread.so.0 #4 0x00000032f6ef197d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fcb7c8c1800 (LWP 823)): #0 0x00000032f6ee8ecf in poll () from /lib64/libc.so.6 #1 0x000000000043066d in ?? () #2 0x0000000000430aad in ?? () #3 0x00000000004041e6 in ?? () #4 0x00000032f6e21735 in __libc_start_main () from /lib64/libc.so.6 #5 0x0000000000404619 in ?? () #6 0x00007fff5e8b5348 in ?? () #7 0x000000000000001c in ?? () #8 0x0000000000000007 in ?? () #9 0x00007fff5e8b5de6 in ?? () #10 0x00007fff5e8b5df7 in ?? () #11 0x00007fff5e8b5dfe in ?? () #12 0x00007fff5e8b5e0a in ?? () #13 0x00007fff5e8b5e0c in ?? () #14 0x00007fff5e8b5e1c in ?? () #15 0x00007fff5e8b5e1e in ?? () #16 0x0000000000000000 in ?? () This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |