[apport] planner crashed with SIGFPE when resizing a task

[PresuntoRJ]

Binary package hint: planner

I was able to reproduce in several ways, but it most commonly happens if you already have a set of tasks, try to link two tasks (one as the other predecessor) with the default zoom on the Gantt view.

If the one you click to drag the arrow was created with a very small profile due to a very short duration (i.e. 1h), the mouse usually get stuck in the resize mode (right white arrow with a limit), the application freezes and than crashes.

It happened more often on the 0.14.1 version but I still got at least three times in less than two hours using the 0.14.2 (currently available on Feisty beta).

The only known workarround is to avoid linking such tasks with the mouse. Either edit the interdepency manually (FF, FS, etc) or do the predecessor step prior to resize the task to a shorter period.

It often works fine if you keep the button pressed to actually resize the task duration.

It happend on four of my machine: a Compaq Armada M700 PIII 850Mhz 512M working with a Microsoft Basic Optical Mouse running Feisty, a Dell Precision 220 Workstatio Dual PIII 700 MHz 256M working with a Dell Optical Mouse running Edgy, a Dell Optiplex GX 260 P4 1.8GHz 256M working with a Microsoft Wireless Mouse 2.0 running Edgy and a Compaq iPaq PIII 733Mhz 512M working with a Microsoft Stark Mouse running Dapper;

None of those equipments seem to crash using other GUI applications (Gnome or Kde) regarding Mouse attributes, movements or commands besides this reported issue with Planner.

ProblemType: Crash
Architecture: i386
Date: Sat Mar 31 01:29:41 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/bin/planner
Package: planner 0.14.2-1build1
PackageArchitecture: i386
ProcCmdline: planner
ProcCwd: /home/leitao
ProcEnviron:
 LANGUAGE=pt_BR.UTF-8
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=pt_BR.UTF-8
 SHELL=/bin/bash
Signal: 8
SourcePackage: planner
Stacktrace:
 #0 0xb7f42eb0 in ?? () from /usr/lib/libplanner-1.so.0
 #1 0x00000000 in ?? ()
StacktraceTop:
 ?? () from /usr/lib/libplanner-1.so.0
 ?? ()
ThreadStacktrace:
 .
 Thread 1 (process 22332):
 #0 0xb7f42eb0 in ?? () from /usr/lib/libplanner-1.so.0
 #1 0x00000000 in ?? ()
Uname: Linux arm7 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev scanner video

[Apport retracing service (apport)]

StacktraceTop:task_manager_do_forward_pass_helper (manager=0x8139000, task=0x0) at /usr/include/bits/mathinline.h:530
mrp_task_manager_recalc (manager=0x8139000, force=1) at mrp-task-manager.c:2126
task_manager_task_duration_notify_cb (task=0x8414380, spec=0x8117358, manager=0x8139000) at mrp-task-manager.c:2335
IA__g_cclosure_marshal_VOID__PARAM (closure=0x81786a0, return_value=0x0, n_param_values=2, param_values=0xbfe0092c, invocation_hint=0xbfe0083c,
IA__g_closure_invoke (closure=0x81786a0, return_value=0x0, n_param_values=2, param_values=0xbfe0092c, invocation_hint=0xbfe0083c) at gclosure.c:490

[Daniel Holbach (dholbach)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=377387

[Alexandre Franke (afranke)]

There's a patch in upstream bug report, would someone be kind enough to test it and confirm that it fixes the problem?

[PresuntoRJ (fabio-tleitao)]

I have since upgraded as requested.. I have been using Planner less since the bug report, but in my attempts so far I could not reproduce the faulty state, so it looks that the patch might have solved the issue.