GNOME Bugzilla – Bug 306746
unreacheable code in css_matcher_apply_rule() reached.
Last modified: 2005-09-29 13:32:40 UTC
Steps to reproduce: 1. Load attached document. 2. ... watch the assertion fail. HtmlCss-ERROR **: file cssmatcher.c: line 1317 (css_matcher_apply_rule): should not be reached aborting... Stack trace:
+ Trace 60644
Other information:
Created attachment 47366 [details] test case The gtkhtml test program is expected to crash on this file.
Created attachment 47377 [details] [review] Proposed patch There was an incorrect assumption in the code: unknown attributes do not mean code is incorrect but may mean that supplied document is non-conforming or just conforms to a newer version of CSS standard. In any case, the code should just ignore such cases. FWIW, the simplest test document triggering the assertion is: <HTML><BODY style="text-align: auto;"></BODY></HTML>
The attached test case does not contain any text-align properties, according to gedit's find functionality, and does not seem to crash my gtkhtml2. The proposed patch should not use g_message, and should only change the g_assert_not_reached to g_warning. Why are you changing the other g_warning to a g_message as well?
OK, something went wrong with attaching the message because the version I have on the disk has - but the one attached to the report does not - I see bugzilla stripped values of all style attributes and converted tags to lower case!!! Very nasty. Anyway, you should be able to reproduce the problem with the one-line document mentioned above. Re: g_message() and g_warning(). I do not insist on using g_message but I definetely insist on *not* using g_warning(). My understanding is that g_warning() should report unexpected conditions in the code itself, not report incorrect - but correctly handled - input, which can be beyond program's control. One of the properties of g_warning() is its ability to dump the core when program is run with --g-fatal-warnings. Dumping the core in case of an predicted and acceptable event (like an unhandled attribute) is too rough behavior and just makes difficult to debug real problems with the code.
Created attachment 47380 [details] Same test case attached as text/plain this time Attaching the same HTML document as text/plain so that bugzilla does not mess with it (hopefully).
Created attachment 47382 [details] [review] Patch to fix crash Here is a modified version of the proposed patch which just gets rid of the text-align: bottom; block completely in the switch statement, and uses the same error message for all unhandled alignment types. I'll be committing this to CVS momentarily, on HEAD.
Committed.
*** Bug 315366 has been marked as a duplicate of this bug. ***
Has this gtkhtml2 version been released? I see Fedora development for example still carries the buggy gtkhtml2-2.6.3.
I just released 2.11.0 this past weekend. It contains this fix among several others. It also supports <meta http-equiv="refresh"...> and <link rel="shortcut-icon"...>. I don't plan to make any further 2.6 releases, unless there is some highly compelling reason to backport some of the fixes and make one (Sun/Redhat/etc... require a 2.6 release) though.