When I don't put nls in my use flags, workrave does not compile. "USE=nls emerge workrave" works fine. Reproducible: Always Steps to Reproduce: 1.emerge workrave 2. 3. Actual Results: In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/x86_ 64-pc-linux-gnu/bits/c++locale.h:46, from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/iosf wd:46, from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits /stl_algobase.h:70, from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/bits /char_traits.h:46, from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/include/g++-v3/stri ng:47, from Configurator.hh:22, from Break.cc:26: /usr/include/libintl.h:40: error: expected unqualified-id before "const" /usr/include/libintl.h:40: error: expected `)' before "const" /usr/include/libintl.h:40: error: expected init-declarator before "const" /usr/include/libintl.h:40: error: expected `,' or `;' before "const" /usr/include/libintl.h:44: error: expected unqualified-id before "const" /usr/include/libintl.h:44: error: expected `)' before "const" /usr/include/libintl.h:44: error: expected init-declarator before "const" /usr/include/libintl.h:44: error: expected `,' or `;' before "const" /usr/include/libintl.h:51: error: expected unqualified-id before "const" /usr/include/libintl.h:51: error: expected `)' before "const" /usr/include/libintl.h:51: error: expected init-declarator before "const" /usr/include/libintl.h:51: error: expected `,' or `;' before "const" /usr/include/libintl.h:81: error: expected unqualified-id before "const" /usr/include/libintl.h:81: error: expected `)' before "const" /usr/include/libintl.h:81: error: expected init-declarator before "const" /usr/include/libintl.h:81: error: expected `,' or `;' before "const" /usr/include/libintl.h:85: error: expected unqualified-id before "const" /usr/include/libintl.h:85: error: expected `)' before "const" /usr/include/libintl.h:85: error: expected init-declarator before "const" /usr/include/libintl.h:85: error: expected `,' or `;' before "const" Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.9-gentoo-r14 x86_64) ================================================================= System uname: 2.6.9-gentoo-r14 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 23 2005, 15:29:48)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon64 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon64 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa bitmap-fonts cdr crypt divx4linux dvd emacs esd fbcon font-server gif gpm gtk imap imlib ipv6 jabber java jikes jp2 jpeg live lzw lzw-tiff matrox mbox mp3 msn nas ncurses network opengl pam parse-clocks passfile perl png ppds readline rtc ssl stroke tcpd threads tiff truetype truetype-fonts type1-fonts usb userlocales xml xml2 xpm xrandr xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
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.
