Created attachment 373382 [details] Register screenshot I've experienced several random crashed that cause the Gnocash to either freez or crash. These happen after associating a file (any file) to a transaction from a register view. I was able to reproduce this problem several times just by clicking on/around the "f" flag on the ff/fd column that appears after associating a file. This is the error message from the console running gdb gnucash: env LANGUAGE=he_IL.UTF-8 LANG=he_IL.UTF-8 gdb gnucash GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnucash...(no debugging symbols found)...done. (gdb) run Starting program: /home/avi/opt/bin/gnucash [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. 0x00007ffff46a7fde in gnucash_sheet_style_get_cell_pixel_rel_coords () from /home/avi/opt/lib/gnucash/libgncmod-register-gnome.so (gdb) run
Good enough, it's crashing because gnucash_style_get_cell_dimensions can return NULL and several functions including gnucash_sheet_style_get_cell_pixel_rel_coords dereference the return value without checking. Odd that that code is 19 years old and nobody's bumped up against it before. The FFFD in a square means that either you have an illegal unicode code point or your font doesn't have a glyph for whatever you translated the "A" that appears in that column to. Since that's the string causing the problem in bug 797349 I suppose that you haven't rebased your translation with Frank's fix for it.
I'm not sure I fully understand Frank's fix or how it affects the translation for all I did is using standard Hebrew letters, no formats, no special fonts nor symbols. ok, so this is what I did so far: 1. got all abbreviations on the Hebrew gnucash.po/mo back to what it was; c y n f a "A" "R" U+R. Unfortunately, this did not solve anything. 2. logged-in in English. Was still able to reproduce the crash: Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. 0x00007ffff46a7fde in gnucash_sheet_style_get_cell_pixel_rel_coords () from /home/avi/opt/lib/gnucash/libgncmod-register-gnome.so (gdb)
Yes, I've found the immediate cause of that crash and I'll fix it soon. Here's the comment and msgid for that string: #. Translators: The abbreviation for 'Associate' #. in the header row of the register. Please only #. translate the portion after the ':' and #. leave the rest ("Associate:") as is. #: gnucash/register/ledger-core/split-register-layout.c:711 #: gnucash/register/ledger-core/split-register-model.c:326 msgid "Associate:A" You translated it as msgstr "צ" But the calling function expects the msgstr to begin with untranslated "Associate:" and applies a 10-byte offset on it to find the actual character. With your single-codepoint translation that 10 bytes retrieves some random sequence that's not valid UTF-8 and you get the "no glyph" glyph. The correct translation is msgstr "Associate:צ" with which the offset points at "צ".
right, so I did. I'm going to fix the translation and test it, then push a new he.po file. One thing still puzzles me, why does it crash even if I login in English? SQLing the database only shows ns and ys, no odd characters...
The crash doesn't have anything to do with the translation, it's a coding error. I've pushed a fix for the problem revealed by your debug session and that will be in 3.7 which we're releasing this weekend. That might well just move the crash somewhere upstream so let's leave this open and on NEEDINFO until you can test it.
Sounds good, Thanks John
I believe we can now close this one, this problem did not repeat since i built 3.7 from master.
(In reply to Avi Markovitz from comment #7) > I believe we can now close this one, this problem did not repeat since i > built 3.7 from master. While I'm glad the problem is gone, I'm confused by the part stating "I built 3.7 from master". 3.7 is not on the master branch, but on the maint branch. If you built master, you chose to build a very unstable development snapshot of what is to become gnucash 4.0 at some point in the future. Unless you intend to contribute code to that branch there's currently no reason to build from it and I'd recommend not to do that. Better is to either build from the 3.7 release tar balls, the 3.7 tag in git or from the maint branch. The first two options should give you the same binary, and which we consider the 3.7 release. If you build from maint you'll get 3.7 + bugfixes queuing up for gnucash 3.8.
