GNOME Bugzilla – Bug 324340
crash on cutting element
Last modified: 2010-01-04 07:39:55 UTC
Version details: 0.9.0debian3ubuntu1 Distribution/Version: Ubuntu 5.10 Description of the crash: I opened a DocBook document, and selected a Defined Terms box. In the right hand pane, I did Context menu -> Cut. The application crashed. How often does this happen? Every time.
Joachim, can you attach backtrace please? I know this bug is easily reproducable, but with backtrace it will be much easier to manage this bug.
Created attachment 56275 [details] backtrace for the crash, copied from BugBuddy
Seems unique
Confirming
Created attachment 149837 [details] More detailed backtrace from head revision in git I get the same crash in the current version (from git) when trying to cut a ulink element from the raw-XML view of a DocBook article. Oddly, I can cut other portions of the document just fine, but trying to cut this element or any of its parents makes Conglomerate crash. What's happening is the line manager for this element is trying to look up the per-node data associated with it, but there is no entry for the element in the hash table it maintains for this purpose (hash_of_editor_node_to_data). This causes an assertion failure, which leads to a crash. I've gotten as far as determining the line manager object being asked to remove the node is _not_ the same line manager object associated with the element at the time it's created (when cong_editor_line_manager_add_node is called). This suggests the wrong line manager is being selected at the time the element is cut (possibly by get_line_manager_for_node in cong-editor-widget3.c), or perhaps the element is reassigned to a different line manager at some point but the new line manager's hash table isn't updated to reflect this. I'm still investigating as I have time.
The element's parent is being assigned a new line manager for its children at cong-editor-node-element-span.c:137, in cong_editor_node_element_span_create_areas. Because the child elements aren't re-added and the hash table itself isn't carried over, the per-node data for the child elements is lost, eventually resulting in the assertion failure.
Created attachment 149889 [details] [review] Don't replace the line manager of span elements that already have one Here's a possible patch to fix this. This adds an if-block that makes cong_editor_node_element_span_create_areas not replace the line manager of (parent) span elements that already have one assigned. This means the per-node data of child elements is preserved and the assertion failure doesn't happen. I don't know if this is what was originally intended but it seems logical and appears to solve the problem without side effects.
This patch looks good to me. What's missing IMHO, is a simple testcase reproducing your bug scenario. Unfortunately, Conglomerate is not very well maintained. If we could have such a testcase (and we can execute the testcase against HEAD and your patched version) we could be more confident to not break any things by patching.
Why was this RESOLVED? I can't see the patch in the repository. Can you please add links to the commits when you resolve bugs, please?
http://git.gnome.org/browse/conglomerate/commit/?id=baab71d3cfdf57dfc201e6428948b35724a858af