Crash with -s bryce

[Lionel Dricot]

Starting GTG with -s bryce and switching immediately to workview leads to a trace, after a while:

Traceback (most recent call last):
  File "../liblarch/liblarch/processqueue.py", line 43, in process_queue
    func(*action[1:])
  File "../liblarch/liblarch/tree.py", line 230, in _add_node
    self._callback("node-added", node_id)
  File "../liblarch/liblarch/tree.py", line 80, in _callback
    func(node_id)
  File "../liblarch/liblarch/filteredtree.py", line 139, in __external_modify
    return self.__update_node(node_id,direction="both")
  File "../liblarch/liblarch/filteredtree.py", line 203, in __update_node
    self.__update_node(parent,direction="up")
  File "../liblarch/liblarch/filteredtree.py", line 263, in __update_node
    self.tree.modify_node(parent)
  File "../liblarch/liblarch/tree.py", line 90, in modify_node
    self._external_request(self._modify_node, priority, node_id)
  File "../liblarch/liblarch/tree.py", line 110, in _external_request
    self._queue.process_queue()
  File "../liblarch/liblarch/processqueue.py", line 43, in process_queue
    func(*action[1:])
  File "../liblarch/liblarch/tree.py", line 230, in _add_node
    self._callback("node-added", node_id)
  File "../liblarch/liblarch/tree.py", line 80, in _callback
    func(node_id)
  File "../liblarch/liblarch/filteredtree.py", line 139, in __external_modify
    return self.__update_node(node_id,direction="both")
  File "../liblarch/liblarch/filteredtree.py", line 160, in __update_node
    self.__update_node(parent,"up")
  File "../liblarch/liblarch/filteredtree.py", line 239, in __update_node
    paths = self.get_paths_for_node(node_id)
  File "../liblarch/liblarch/filteredtree.py", line 442, in get_paths_for_node
    raise Exception("%s is not children of %s\n%s" % (node_id, parent_id,str(self.nodes)))

[Izidor Matušov (izidor)]

My steps how to reproduce this bug from clean taskset:

1, Turn on notification area plugin
2, Create tasks set:
A
-> B
---> C
------> D
---------> E
3, Restart GTG

[gdupont (ger-dupont)]

Same issue in my side with an existing (large) set of tasks. Ignore the error allows to somehow consult the current task, but one cannot add new tasks.

[Cyphase (cyphase)]

This definitely seem to be a problem with the notification area plugin, or some code that it's using. I logged in just now and when I tried to start GTG (without -s bryce, whatever that is, and with the notification area plugin enabled), it gave me the error dialog with the same error as the OP after loading 29 tasks (coincidence? ;). However I was able to ignore the error and view the current task list, but not edit it, just like gdupont. However, not all my tasks were visible. Out of my 35 tasks (I've only just started using GTG :P ), it was only showing the 29 earliest tasks (as far as I can tell, and that makes sense). However, a couple of things cause it to show more tasks. When I edited the description text of a note (and I confirmed that the change was saved to the backend file), the count of visible tasks went to 32. And regardless of whether I did that first or not, when I opened the Preferences dialog, all 35 notes became visible. However, I still could not edit the list.

Going into Preferences, disabling the notification area plugin and restarting GTG completely fixes the problem.

A final note: Izidor's comment has him creating a task list that's 5 tasks deep to reproduce the problem. My deepest task tree is 4 deep, but that's not to say that even less wouldn't still trigger the bug.

[Ted (tedks)]

I spent an hour or so looking at this, and I can confirm that the problem lies in the notification area's attempt to get a workview view of the task tree before the tree has been loaded by the backend. I can reliably avoid the bug if I put a return statement just before these lines in notification_area.py:

        return
        self.__tree.apply_filter('workview')
        self.__tree.refresh_all()

I don't know very much about the gtg internals, but my guess is that there's some threading issues in liblarch related to multiple views manipulating a rapidly changing tree. The real fix would be to fix that bug.

As a stopgap, removing the threading from task loading also fixes the problem, and isn't noticeably slower on a large (~150 active tasks, many, many more deactivated tasks) backend. Slower backends would almost certainly suffer, but it's reasonable to expect slower startup times with slower backends, and until the tasks are loaded, you can't do anything with gtg anyway.

[Ted (tedks)]

On Tue, 2012-03-06 at 08:09 +0000, Izidor Matušov wrote:
> Ad anonymize script: I've reported bug #947792, I will work on it.
>
> If you want to test it with scripts/debug.sh, there is a script for
> that:
>
> scripts/import_my_tasks_into_debug_tasks.sh
> scripts/debug.sh
>
> I am not able to reproduce your bug probably because of crash with -s
> bryce (bug #931555). Is there any output from GTG in terminal?
>

I notice this even when I get lucky and don't get the -s bryce crash,
but I've found that I can avoid that crash completely by removing the
threading from task initialization, as in the patch attached.

There's no output from gtg out of the ordinary when I run without
debugging; I'll try running with debugging following your instructions
and see what I can find.

(I'm cc'ing this email to bug #931555, mostly to see if it'll attach the
workaround patch to that ticket.)

[Ted (tedks)]

lp:gtg r1104 fixes this bug, at least on my setup. I also don't get any relationship loss. Woohoo!

[Izidor Matušov (izidor)]

Ted: I believe, I've solved it by this commit in LibLarch: https://github.com/liblarch/liblarch/commit/a7fec3615c01d3f9cab19d54053e7bee30e4a41f

Does it solve the loosing of relationships for you?

[Ted (tedks)]

With stock Ubuntu 11.10 liblarch and gtg trunk, as of r1104, I haven't had any crashes or relationship loss. I'll test that version of liblarch later today.

[Ted (tedks)]

Spoke too soon -- I still don't get crashes, but I am experiencing relationship loss. I'll try the new liblarch.

[Ted (tedks)]

I can confirm that no relationship loss occurs with trunk gtg and trunk liblarch.

Woohoo! (hopefully for real this time)

[Ted (tedks)]

I still haven't gotten crashes, but I do get lots of relationship loss. I think that's a seperate bug.

[Izidor Matušov (izidor)]

Please report a separate bug if you find more information.