GNOME Bugzilla – Bug 136044
Plan broken after saving it (complex plans)
Last modified: 2004-12-22 21:47:04 UTC
When the plan gets very complex, like 20 or more task, with some subtasks and milestones and dependencies it happens with a certain regularity that the plan gets broken after saving is. That is if you make some edits, save the file, exit Planner and open the plan again, you see a corrupted plan (one or more tasks are not shown on the GANTT chart). I have a file to reproduce the problem, at http://www.dinisio.net/nicola/tmp/simlin2.mrproject please download it and load it on planner 0.11. You can see that the task SRS-preparation depends on the task "kick-off", but notwithstanding that it is not shown at all, dates and effort are lost... To fix such a plan I have to delete the dependency and use the Must-Start-On setting for the task. This bug is present on MrProject 0.9.1 (shipped along SuSE 8.2) and on Planner 0.11 as well. My Planner 0.11 is running on SuSE 8.2 and comes from the Packman Team build planner-0.11-0.pm.0.i586.rpm planner-kde-0.11-0.pm.0.i586.rpm and I have fixed a couple of "prerequisites" to make it install on SuSE 8.2 withou changin the SSL stuff: cd /usr/lib ln -s libssl.so.0.9.6 libssl.so.0.9.7 ln -s libcrypto.so.0.9.6 libcrypto.so.0.9.7 ln -s libpopt.so.0 libpopt.so.1 But I don't think this is influencing the bug, because it is present also on the official SuSE 8.2 mrproject 0.9.1 package. I got the bug reproduced both at home and at the office (both SuSE 8.2 machines, but possibly differently configured, both running KDE, 3.2 and 3.1.4 respectively) I am available to test any fixes for this bug.
When I load you reference project up then I get... (planner:12237): GLib-CRITICAL **: file gnode.c: line 274 (g_node_insert_before): assertion `parent != NULL' failed (planner:12237): GLib-CRITICAL **: file gnode.c: line 274 (g_node_insert_before): assertion `parent != NULL' failed (planner:12237): GLib-CRITICAL **: file gnode.c: line 274 (g_node_insert_before): assertion `parent != NULL' failed and if I delete the SRS-preparation and then save and then reload the saved project then I don't get that message. Once I've deleted that then it also run much faster. Now the hard part is drilling down into these linked lists to track that bug down and trying to find out why.
SRS-preparation was depending on the "kick-off" milestone. I noticed that removing that dependency and making SRS-preparation start no a fixed date (Must start on) cured the problem and since then it never came back.
I'm trying to track down the problem with the g_node_insert_before() ,See bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=136044 Its not that gnode function but actually it is a g_node_append() in mrp-task-manager.c : task_manager_sort_tree () thats using a null for the parent. I found that gnode.h defines g_node_append() as g_node_insert_before(parent,NULL,node) OK so how does the parent get set ?. In task_manager_sort_tree() we have a loop and it walks through the tasks (which is fine as I added some debug code and it counts 44 tasks in the sample project (see the bugzilla) but three tasks have a null parent. These are the same 3 tasks that have no start date and have weird gantt links. The key command is.... parent_node = g_hash_table_lookup (hash,mrp_task_get_parent (task)); and it returns a NULL (in 3 cases) so my question is which routine actually sets up the parent for a task ?. Something in that set is borked. Rgds, Lincoln.
Created attachment 25547 [details] A smaller test project that is broken.
In the smaller planner attachement http://bugzilla.gnome.org/showattachment.cgi?attach_id=25547 notice the dates on the 3 broken tasks as being 19700101T000000Z i.e. zero-date in Unix in 1970. As to why they got there its because of all the constraints working against each other I think but I'm manually looking at that file to see if I can work out how to trap this in code. The g_node_...parent NULL stuff is a symptom and more a red herring. It may be that the file was corrupted from startup but if this is the case then the file loader should do some basic sanity checks e.g. !(task-start < project-start) and !(task-end < project-start) would clean up some stuff. Rgds, Lincoln.
*** Bug 137429 has been marked as a duplicate of this bug. ***
The bug is that the sorting algorithm that is used to sort the tree in order to do CPM is a bit broken. It has nothing to do with the constraints or the times, that's just a symptom. The bug is easy to reproduce, it involves creating subtasks under two different main tasks and have links between the children of in both ways.
The algorithm is described in docs/Scheduling by the way.
I started fixing this a while ago, I have a half-finished patch.
The branch new-sched fixes this, but needs a bit more work.
Fixed in CVS.