Summary: | workrave 1.6.2 crashes on exercises | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maik Nijhuis <manyac> |
Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED UPSTREAM | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Maik Nijhuis
2005-03-28 00:11:58 UTC
Thank you for your report. I've added a patch to resolve this problem. Please try again after sync'ing your portage tree and let us know how it goes. It works perfectly now, thanks for the quick response! Hmmm.. Apparently it doesn't work that good. Whenever the program wants to do something with exercises, it crashes. Just picking the exercises-option from the menu gets you a segmentation fault. But.. I managed to fix it :-) I found out that the p pointer in nls.c, line 62, becomes invalid after p = strtok (NULL,"\t "); This is probably a bug in libc. The man-page for strtok clearly says "Never use these functions.", now I know why :-) My solution is quite dirty: I inserted 'p = (int)p & 0x7fffffffff;' after the strtok call, just before 'if (!g_hash_table_lookup (alias_table, buf))' I hope you can use this information. I don't know if it is wise to include a patch that includes this line. For now, I'll use it, until it breaks again. Hi, Sorry for the late reply. I've tried to reproduce the crash, but haven't been able to. What is the backtrace from the process and the rationale behind doing "p = (int)p & 0x7fffffffff;"? Also, in the future please open a new bug report when you find new issues, as this new problem is different in nature to your original report (the right action would be to open a new report, not re-open this one). Thanks. I tried to reproduce the bug, but now the situation is even worse: I get a segmentation fault during startup... With USE=debug I get this error (twice): (workrave:21663): Gtk-CRITICAL **: gtk_table_resize: assertion `n_cols > 0 && n_ cols < 65536' failed And this warning: (workrave:21663): gtkmm-WARNING **: gtkmm: Attempt to call Gtk::manage() on a Gt k::Window, but a Gtk::Window has no parent container to manage its lifetime. The debug output ends with: (workrave:21663): Gtk-CRITICAL **: gtk_table_resize: assertion `n_cols > 0 && n_ cols < 65536' failed <<< TimerBoxGtkView::init_table <<< AppletWindow::init_tray_applet <<< AppletWindow::init_applet <<< AppletWindow::init In gdb the following comes after if I do a backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 21714)] 0x00000000006fbee0 in ?? () (gdb) bt #0 0x00000000006fbee0 in ?? () #1 0x00002aaaac4fc028 in sigc::internal::trackable_callback_list::~trackable_callback_list() () from /usr/lib/libsigc-2.0.so.0 #2 0x00002aaaac4fc0a8 in sigc::trackable::notify_callbacks() () from /usr/lib/libsigc-2.0.so.0 #3 0x00002aaaac4fc717 in sigc::slot_base::~slot_base() () from /usr/lib/libsigc-2.0.so.0 #4 0x00000000004593ab in sigc::slot0<void>::~slot0() () #5 0x000000000045e827 in sigc::slot<void, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::~slot() () #6 0x000000000045df47 in SigC::Slot0<void>::~Slot0() () #7 0x000000000045c1c4 in GUI::init_gui() () #8 0x000000000045afd4 in GUI::main() () #9 0x000000000049061c in run () #10 0x0000000000490663 in main () About the rationale behind 'p = (int)p & 0x7fffffffff;': In the code I saw 'p' has to point somewhere into 'buf'. However, after the strtok(), p became illegal (the upper 25 bits of this 64-bit pointer became 1, IIRC). By anding these bits away I got a pointer that points into buf again. Hi Maik. Thank you for the information. However, I'm still unable to reproduce the problem in nls.c (I can't test on a 64-bit box), and the new problem, which looks like maybe a race condition in frontend/gtkmm/src/TimerBoxGtkView.cc. At this point it's clear that the upstream release is buggy and fixing these issues is kind of tricky. Things like not using strtok() and checking that the arguments to the resize() method of a GtkTable are valid might need to be patched several times throughout the code, and the current design and code style of the software makes this non-trivial. It also doesn't help that development of workrave by its upstream maintainers seems to have staled lately. However, if you get to create any usable patches to correct these problems, I'll gladly consider them. Thanks. |