GNOME Bugzilla – Bug 772803
Inline images cause busy loop on Reply in WebKitWebProcess
Last modified: 2016-11-02 12:37:32 UTC
Arch Linux amd64 Broke in upgrading from Evolution 3.22.0 to 3.22.1 Composing a message from scratch opens window as appropriate. Hitting Reply to Reply to All on a message opens new message window with the composer section blank (no original email, no signature, no active cursor). Clicking in the window to type does nothing. Attempting to type in window does nothing. I have -ews installed, if that makes a difference.
(In reply to Benjamin Selzer from comment #0) > Arch Linux amd64 > > Broke in upgrading from Evolution 3.22.0 to 3.22.1 > > Composing a message from scratch opens window as appropriate. > > Hitting Reply to Reply to All on a message opens new message window with the > composer section blank (no original email, no signature, no active cursor). > > Clicking in the window to type does nothing. Attempting to type in window > does nothing. > > I have -ews installed, if that makes a difference. I have the same issue after updating to 3.22.1 and I', also on Arch
Maybe I'm on to something. I launched both versions of Evolution from the command line. The results are this: First, I launched 3.22.0 (the one that works). When I click Reply to an email, my Terminal says (twice): ** (WebKitWebProcess:7395): CRITICAL **: void webkit_dom_element_set_attribute(WebKitDOMElement*, const gchar*, const gchar*, GError**): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:7395): CRITICAL **: void webkit_dom_element_set_attribute(WebKitDOMElement*, const gchar*, const gchar*, GError**): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed HOWEVER, then the email renders perfectly. Second, I launched 3.22.1 (the one that doesn't work). When i click Reply to an email, my Terminal says (HUNDREDS AND HUNDREDS OF TIMES OVER AND OVER): ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed ** (WebKitWebProcess:6836): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed It keeps going and going and going, and will continue until I close the failed composer window. I notice the messages are slightly different, with a different WebKitWebProcess number. My webkit2gtk is up to date, so I'm at a loss. Not sure if that's related. [benjaminselzer@pixel pkg]$ yaourt -Q webkit2gtk extra/webkit2gtk 2.14.1-1 Any ideas?
Thanks for a bug report. Could you provide a simple test message as a reproducer, please? It seems to me like some change for 3.22.1 caused a busy loop in the composer code for some reason. That's only a blind and wild guess. Also, could you install packages with debugging information (no need of debug info for webkit2gtk itself), then grab a backtrace of the WebKitWebProcess (it's process ID is shown on each critical warning in the console, where at the previous comment it's number 6836). You can get the backtrace with command like this: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). The backtrace will show what the process it trying to do. Thanks in advance.
Milan: Thank you for the response. I'm new at this, so please help a little: 1.) I have attached a samples message which I cannot reply to. Is that what you wanted from me? 2.) I installed gdb, then I ran Evolution via gdb: $ gdb evolution r Then I performed the problem function (Reply to message). I could see in the Terminal the similar errors, but it was process 9339 this time: ** (WebKitWebProcess:9339): CRITICAL **: gchar* webkit_dom_element_get_attribute(WebKitDOMElement*, const gchar*): assertion 'WEBKIT_DOM_IS_ELEMENT(self)' failed I then quit Evolution and ran: $ gdb --batch --ex "t a a bt" -pid=9339 &>bt.txt I have attacehd bt.txt. It just says: ptrace: No such process. What did I do wrong? Sorry, I am not experienced, but I am trying!
Created attachment 337564 [details] Sample message
Created attachment 337565 [details] Empty bt.txt
Hi, the email doesn't cause any issues for my Evolution from the Arch extra repository. Regarding debugging I already provided a pointer: "Perhaps you need to debug, https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Gdb ." - https://mail.gnome.org/archives/evolution-list/2016-October/msg00069.html OTOH prefer this clear guide https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#General over this confusing instruction https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Gdb IOW "These settings will force compilation with debugging information and will disable the stripping of debug symbols from executables. To apply this setting to a single package, modify the PKGBUILD: options=(debug !strip)" should be all you need to do. I also mentioned ABS, https://wiki.archlinux.org/index.php/Arch_Build_System and that you first need to build and install evolution-data-server and after that evolution, resp. evolution-ews. [rocketmouse@archlinux ~]$ ls -hAl /var/abs/extra/evolution* /var/abs/extra/evolution: total 4.0K -rw-r--r-- 1 root root 2.7K Oct 13 00:07 PKGBUILD /var/abs/extra/evolution-data-server: total 4.0K -rw-r--r-- 1 root root 1.4K Oct 13 00:07 PKGBUILD /var/abs/extra/evolution-ews: total 4.0K -rw-r--r-- 1 root root 1.2K Oct 13 00:07 PKGBUILD Regards, Ralf
My apologies, after "Don't lose formatting" the bug affects me, too. Usually I use "Lose formatting", so I didn't notice it in the first place. Regards, Ralf
OK so we cannot reply in HTML. This clearly seems like a bug. I appreciate your tips. I will try to figure it out later, but I am just a beginning. I am not familiar with editing PKGBUILD's. Since it's effecting you, are you able to provide the debugging information? Thank you for the continued follow up.
Thanks for the update. The sample message is perfectly fine, I can reproduce it with it too, which is much better than the backtrace. Just to answer, ptrace is a process which gdb calls to get the information about the process. You do not have it installed, which is fine now, because of the test message.
The backtrace I was looking for looks like this (git master):
+ Trace 236737
OK thank you. Sorry I wasn't able to product it. There is something wrong with the HTML composer in 3.22.1. For instance, put on a dark theme. In 3.22.0, if I compose a fresh HTML message, the composer area is white. This is correct, because HTML works from a while blank slate. However, in 3.22.1, the HTML composer is taking on the dark background. I do not believe this is correct. The way it works in 3.22.0 renders and composes HTML properly. The way it works in 3.22.1 is the way it worked in 3.20 with dark themes, and it made problems composing messages in HTML mode. Is there something else that you need from me?
So the webkit_dom_node_list_get_length() can actually return 0, then the construction: 8422 for (jj = webkit_dom_node_list_get_length (list) - 1; jj--;) { starts with jj = -1, thus it will eventually stop (get to 0) once it does it 2^32 times, +/- 1 or so. I see the similar construction is used widely in this source file. A safer option is: 8422 for (jj = webkit_dom_node_list_get_length (list) - 1; jj >= 0; jj--) {
OK. Do I need to change something? I am not familiar with the process. This is my first bug report ever :)
(In reply to Milan Crha from comment #13) > starts with jj = -1 Oops, no, it starts with -2 instead. Thus this change works too: 8422 for (jj = webkit_dom_node_list_get_length (list); jj--;) { (In reply to Benjamin Selzer from comment #12) > OK thank you. Sorry I wasn't able to product it. That's okay, the test message is much better, because it allows testing here, which saves time both for you and for the developer (being able to reproduce the issue is always a plus). > For instance, put on a dark theme. Might be something to do with bug #772233. (In reply to Benjamin Selzer from comment #14) > OK. Do I need to change something? I am not familiar with the process. This > is my first bug report ever :) Not as of now. You can just watch as the bug get fixed and then either wait for the change to be available in your distribution or apply the change locally.
Created commit d74c18b in evo master (3.23.1+) Created commit 94d226c in evo gnome-3-22 (3.22.2+)
Thanks! Can you give me a hint on how to patch locally? Sorry I'm such a dodo :)
You don't need to apply a patch, just build from git git clone git://git.foo.org/foo.git cd foo/ then either git checkout abcd1234 or git pull --all However, better build based on ABS or AUR PKGBUILDs, but consider to read the source code's READMEs, autogen.sh vs cmake. The GNOME bug tracker unlikely is the right place to continue this kind of requests. Please use an appropriate support forum and before doing this consult the Arch Wiki.
You're right. Thank you.
*** Bug 773772 has been marked as a duplicate of this bug. ***
*** Bug 773539 has been marked as a duplicate of this bug. ***