GNOME Bugzilla – Bug 650174
crash when solving any operation
Last modified: 2011-06-15 08:19:32 UTC
When hitting Enter or clicking '=' for any operation, even 1+1, gcalctool crashes: cerebrum:jasper {101} gdb gcalctool GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.9"... (gdb) run Starting program: /usr/local/bin/gcalctool [New process 22871, thread 0x86410000] [New process 22871, thread 0x86a41c00] [New process 22871] [New process 22871, thread 0x805d1000] Program received signal SIGSEGV, Segmentation fault. [Switching to process 22871, thread 0x805d1000] 0x1c02580f in _mp_equation_parse (yyscanner=0x802ec800) at mp-equation-parser.c:1708 1708 yychar = YYLEX; (gdb) bt
+ Trace 227118
-29220, 10919, 3104, 2915, 18266, 7170, 1616, -32181, 0, 0, 4, 0, -21484, 9161, 3276, 15361, 3104, 2915, 24456, -30794, -13516, 978, -14336, -32722, -14336, -32722, 24472, -30794, 16939, 7170} yyss = (yytype_int16 *) 0x87b65df0 yyssp = (yytype_int16 *) 0x87b65df0 yyvsa = Cannot access memory at address 0x879d5db0 (gdb) The used bison was: (GNU Bison) 2.3 Any pointers on how to further debug this?
So, I tracked down the offending commit which caused the issue with a git bisect: 36c10ea78406dbe87a2db600101f5867311fce82 is the first bad commit commit 36c10ea78406dbe87a2db600101f5867311fce82 Author: Robin Sonefors <ozamosi@flukkost.nu> Date: Wed Oct 13 01:13:34 2010 +0200 Initial threading implementation (bug #576371) Cannot be aborted, and information about background calculations is displayed in an ugly way. :040000 040000 e3a55c16024b41e1d8dad4f0751eb7083a8cc2e8 04f4c9c46a76b89aedd7531c968b7e2c65f2f6b0 M src I'd be happy to test diffs now it's know where the root lies of my crashes.
This is caused by a stack overflow now that threading is being used. On some platforms, the default thread stacksize is not larger enough to hold the lexical analyzer. This diff corrects the problem on FreeBSD and should work on other platforms as well: --- src/math-equation.c.orig 2011-05-30 19:16:53.000000000 -0400 +++ src/math-equation.c 2011-05-30 19:19:35.000000000 -0400 @@ -1305,6 +1305,7 @@ void math_equation_solve(MathEquation *equation) { GError *error = NULL; + gulong stacksize = 0; g_return_if_fail(equation != NULL); @@ -1326,7 +1327,13 @@ math_equation_solve(MathEquation *equati math_equation_set_number_mode(equation, NORMAL); - g_thread_create(math_equation_solve_real, equation, false, &error); + if (GLIB_SIZEOF_LONG == 8) { + stacksize = 0x400000; + } else { + stacksize = 0x200000; + } + + g_thread_create_full(math_equation_solve_real, equation, stacksize, false, false, G_THREAD_PRIORITY_NORMAL, &error); if (error) g_warning("Error spawning thread for calculations: %s\n", error->message);
I can confirm this fixes the issue on OpenBSD.
I've applied this patch. It's hacky, so I've added some comments. Hopefully this problem will go away when the parser is rewritten, see bug 589569