Created attachment 372896 [details] tracefile Windows 10 Pro 64-bit version 1803 Memory integrity: On Newly installation of GnuCash from version 3.0 to 3.2 crash at start up. The .gnucash folder under user folder is not created. Older versions from 2.6.19 to 2.6.21 work fine. After each crash, the tracefile is empty. Running GnuCash with option "gnucash --debug --extra" produces no warning or error message (tracefile attached). Tested installation option: with/without Translation package.
Does the splash screen display? Do you get a "application requested the runtime to terminate" or "application has stopped working" dialogs? Please try running "gnucash --log gnc=debug" and attach the resulting tracefile. Can you set up a build environment (https://wiki.gnucash.org/wiki/Building_on_Windows) or install https://github.com/jrfonseca/drmingw to get a stack trace (https://wiki.gnucash.org/wiki/Stack_Trace)?
Created attachment 372897 [details] tracefile (In reply to John Ralls from comment #1) > Does the splash screen display? Do you get a "application requested the > runtime to terminate" or "application has stopped working" dialogs? I get the splash screen which says "Loading..." at the bottom. No error dialog, the program just terminates quietly. > Please try running "gnucash --log gnc=debug" [...] Tracefile attached. > Can you set up a build environment [...] I will return with a stack trace after I finish setting up my build environment.
(In reply to John Ralls from comment #1) > Can you set up a build environment > (https://wiki.gnucash.org/wiki/Building_on_Windows) or install > https://github.com/jrfonseca/drmingw to get a stack trace > (https://wiki.gnucash.org/wiki/Stack_Trace)? The output from gdb and catchsegv are attached.
Created attachment 372898 [details] gdb
Created attachment 372899 [details] catchsegv
Comment on attachment 372898 [details] gdb This is Guile asserting because scm_getc has asked to parse a multi-byte code point that begins with an ASCII character. Since it's an assert gdb needs a bit of help creating a useful stack trace. Before starting gnucash at the (gdb) prompt tell it b exit That will tell gdb to stop before exiting and you can get a complete stack trace from there.
Created attachment 372901 [details] gdb (In reply to John Ralls from comment #6) I attached the stack trace, but it seems that gdb does not produce any useful information. I'm afraid that I'm not familiar with GNU tool chain.
That's weird, it's a different crash. What was in the trace file from that run?
(In reply to John Ralls from comment #8) From that run, the trace file is just empty. I have tested on other PC: - Windows 7 Pro SP1 64-bit: GnuCash run flawlessly - Windows 10 Pro v1709 64-bit: I get an "application requested the runtime to terminate" error. I will try to get the trace file and stack trace ASAP - GnuCash 2.6.21 works on those PC without any problem.
Request the runtime to terminate is an assert, so you'll need to break on exit to get a useful trace. It might take a little persistence if there's something else going on. It seems from the second tracefile not to get to session load. Does it crash even if you do 'gnucash --nofile'? Another useful check is to create another user, switch to that user, and launch GnuCash. If that doesn't crash then it indicates the problem is something to do with the first user's environment which can be a useful clue.
GnuCash crashes even if I do 'gnucash --nofile'. With new user, the problem persists. Since I have two Windows 10 PC with this crash: - PC1: Windows 10 v1803, GnuCash quits quietly - PC2: Windows 10 v1709, GnuCash crashes with a dialog "This application has requested the Runtime to terminate it in an unusual way". One thing I notice is that, on both PC, after I click the GnuCash icon in Start Menu, it spawns two processes. While GnuCash 2.6 spawns only one. On PC2, I can go as far as seeing the Tip of the day, the second process starts after I click OK on the Runtime error dialog, when the dialog say "windows is collecting more information..." popups.
Created attachment 372902 [details] gdb2 gdb log of PC2, one different line to PC1: (gnucash.exe:8672): Gdk-WARNING **: gdkwindow-win32.c:2303: GetClientRect failed with code 1400: Invalid window handle.
Created attachment 372903 [details] gdb2_b gdb log with stack trace of PC2, the call stack is different to PC1
Did you try 'gnucash --nofile'? That will prevent loading your datafile, which will tell us whether it's the problem or not.
I have tried 'gnucash --nofile', however, the trace files appear to be no difference.
OK, that means that it's crashing before it gets to loading your datafile. The second process that launches when you click on the Runtime Error dialog is Windows trying to help debug the problem. Unfortunately we don't use the normal Windows toolchain so Windows can't understand what it finds. The second machine is asserting at the same place, so whatever's going wrong it's consistent even if the two machines behave differently. I wonder if there's a problem with the Vietnamese translation. Can you try changing the system language or editing C:\Program Files (x86)\gnucash\etc\gnucash\environment (you'll need to run the editor "as administrator") by uncommenting the lines that begin with LANG and LANGUAGE; change the LANG one to a language you understand. en_US will use no translation file at all.
I have changed the LANG parameter to en_US, and this seems to make no different.
Created attachment 372907 [details] gdb After a not so successful attempt to compiling GnuCash on Windows, at least now I can get some symbol table. This time I debug GnuCash under the MINGW32 shell instead of the MSYS shell.
Good work. That moved us quite a bit further. As an experiment I tried setting the locale of my Win10 VM to Vietnam and now get a the same assert, though on a different string. This is clearly a Guile bug: The strings in question are hard-coded into GnuCash and are plain ASCII. Unfortunately I don't think that there's any way to tell Guile to use a different locale than the one set for your system and I doubt you want to change that setting just to use GnuCash. The rest is for Geert in the event that he wants to follow up on this in his morning: Changing scm_c_eval_string() to scm_eval_string(scm_from_utf8_string()) didn't work. New stack trace: #0 0x75105df5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll #1 0x750fb4d8 in msvcrt!abort () from C:\WINDOWS\System32\msvcrt.dll #2 0x70853d5c in _wassert (_Message=_Message@entry=0xb00e9d8 L"size == 1", _File=_File@entry=0xb00ea08 L"C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/ports.c", _Line=_Line@entry=1175) at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/misc/wassert.c:54 #3 0x70853df9 in _assert (_Message=0x7088a80c <scm_cons.name_string_stringbuf+860> "size == 1", _File=0x7088a57c <scm_cons.name_string_stringbuf+204> "C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/ports.c", _Line=1175) at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/misc/wassert.c:30 #4 0x707e11b0 in utf8_to_codepoint (size=<optimized out>, utf8_buf=0x69f4bc "d <\001\066") at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/ports.c:1175 #5 get_iconv_codepoint (len=0x69f4f4, buf=0x69f4fc " ??\001\b", codepoint=0x69f4f8, port=0xd9a28a0) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/ports.c:1399 #6 get_codepoint (port=port@entry=0xd9a28a0, codepoint=codepoint@entry=0x69f4f8, buf=buf@entry=0x69f4fc " ??\001\b", len=len@entry=0x69f4f4) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/ports.c:1433 #7 0x707e184b in scm_getc (port=port@entry=0xd9a28a0) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/ports.c:1475 #8 0x707ef075 in flush_ws (port=port@entry=0xd9a28a0, opts=opts@entry=0x69f698, eoferr=eoferr@entry=0x7088e950 <scm_read_delimited_x.name_string_stringbuf+3296> "scm_i_lreadparen") at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/read.c:339 #9 0x707ef242 in scm_read_sexp (chr=chr@entry=40, port=port@entry=0xd9a28a0, opts=opts@entry=0x69f698) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/read.c:457 #10 0x707ee0be in read_inner_expression (port=0xd9a28a0, opts=<optimized out>) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/read.c:1825 #11 0x707eeff5 in scm_read_expression (port=port@entry=0xd9a28a0, opts=opts@entry=0x69f698) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/read.c:1885 #12 0x707ef72b in scm_read (port=0xd9a28a0) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/read.c:1974 #13 0x70828f6f in vm_regular_engine (vm=0xd5599e8, program=0x70867b20 <scm_read.subr_raw_cell>, argv=0x69f8a4, nargs=223805672) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/vm-i-system.c:855 #14 0x7079c038 in scm_call_1 (proc=0xd895af0, arg1=<optimized out>) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/eval.c:486 #15 0x70828ff9 in vm_regular_engine (vm=0xd5599e8, program=0x708729c8 <scm_call_with_input_string.subr_raw_cell>, argv=0x69fa74, nargs=223805572) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/vm-i-system.c:858 #16 0x7079c0c0 in scm_call_3 (proc=0xd88f6d0, arg1=arg1@entry=0xd711bd0, arg2=arg2@entry=0xd719c40, arg3=arg3@entry=0xd562500) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/eval.c:500 #17 0x7080f1af in scm_eval_string_in_module (string=0xd711bd0, module=0xd562500) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/strports.c:569 #18 0x7080f7c7 in scm_eval_string (string=0xd711bd0) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/strports.c:577 #19 0x0040350d in inner_main (closure=0x0, argc=1, argv=0x7c16068) at C:/gcdev64/gnucash/maint/src/gnucash-git/gnucash/gnucash-bin.c:610 #20 0x707b9d40 in invoke_main_func (body_data=0x69fe90) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/init.c:341 #21 0x70792a10 in c_body (d=0x69fde4) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/continuations.c:517 #22 0x70828ff9 in vm_regular_engine (vm=0xd5599e8, program=0xd5561d0, argv=0x69fd20, nargs=223805532) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/vm-i-system.c:858 #23 0x7079c118 in scm_call_4 (proc=0xd621a68, arg1=arg1@entry=0x404, arg2=arg2@entry=0xd711c60, arg3=arg3@entry=0xd711c50, arg4=arg4@entry=0xd711c40) at C:/gcdev64/gnucash/maint/src/guile-2.0.14/libguile/eval.c:507 #24 0x708153e4 in scm_catch_with_pre_unwind_handler (key=0x404, thunk=0xd711c60, handler=0xd711c50, Diagnosis: scm_eval_string_in_model calls scm_call_with_input_string_string(). That creates a port that is read from, see https://www.gnu.org/software/guile/manual/html_node/String-Ports.html. It notices the opening '(' and calls flush_ws (frame 8) that calls scm_getc (frame 7) that in turn calls get_codepoint(). This is where it fails: http://git.savannah.gnu.org/cgit/guile.git/tree/libguile/ports.c?h=v2.0.14#n1430, if (pti->encoding_mode == SCM_PORT_ENCODING_MODE_UTF8) There are clearly two problems here: First, the string has already been converted to UTF32, so converting it again isn't the right thing to do. Second, pti->encoding_mode *isn't* UTF8 so it calls get_iconv_codepoint, frame 5, http://git.savannah.gnu.org/cgit/guile.git/tree/libguile/ports.c?h=v2.0.14#n1338.
Thanks for the follow-up John. A few more technical considerations: Well if it's a bug in guile it's a documented bug. From the description of scm_c_eval_string: scm_eval_string, but taking a C string in locale encoding instead of an SCM. https://www.gnu.org/software/guile/manual/html_node/Fly-Evaluation.html So we have to convert our strings to locale before passing them to guile :( So my inital half-baked idea yesterday did think in the right direction, but scm_to_locale_string is not the right function to use. We will probably have to check into iconv for this. The other option is to force a different locale on guile (using setlocale). That becomes tricky because we want utf8 for our internal strings and the system locale when evaluating path names.
Geert, Yes, the localization of scm_c_eval_string is documented, but the localization of scm_eval_string is not; it happens in module/ice-9/eval-string.scm. I suspect the only practical solution is to write our own gnc_eval_scheme_string that bypasses ice-9's version.
On windows 10 pro version 1803 GNU 3.4 was working fine with me. After the upgrade to windows 10 pro version 1809 GNU crashes during startup. installing gnucash 3.4 was no issue. starting gnucash resulted in a short window popup and than gnucash got terminated. Installed a fresh clean windows 10 pro os (English version with Dutch regional settings) with the windows updates and installed gnucash 3.4 again. During the install process, I did not get any error messages. upon starting the program for the first time resulted in a short popup screen and then it closes it self again. For the time being I installed a virtual windows 7 machine with gnucash 3.4 and am now able to continue working with this nice piece of software. With some luck the next update will work on windows 10 pro 1809
I finally got Guile 2.2 to build on Windows and reconfigured the Windows build to use the result. This fixes the crash for me, I can now start up in Vietnamese. Hoàng Ngọc Long please test the latest nightly build at https://code.gnucash.org/builds/win32/maint.
Hello John, I test with the build gnucash-3.5-2019-04-30-git-3.5-133-g114efe593+.setup, and it works for me in Vietnamese locale. Thank you for the fix.
