GNOME Bugzilla – Bug 782144
git-master - Save Corrupts Data File / Not Open Data File
Last modified: 2018-06-29 23:56:36 UTC
In http://code.gnucash.org/builds/win32/master/gnucash-2.6.99-2017-04-29-git-1a3595c+-setup.exe if just opening and saving you destroy the data file. When we tried to reopen it, we received the message "There was an error parsing the file". Steps to reproduce: 1 - Open a data file, save and reopen it.
Is this still happening with gnucash 2.7.8 ? If so, please attach a trace file from both the first (successful) run and the second failing one. Also what backend do you use ? xml, sqlite, mysql or postgresql ?
(In reply to Geert Janssens from comment #1) > Is this still happening with gnucash 2.7.8 ? > I installed version 2.7.8 on my VM (W10 RS3) and when I tried to open my XML data file I received an error message (See attached screenshot) and I was not able to do this test. > If so, please attach a trace file from both the first (successful) run and > the second failing one. > What is the extension of the trace file (is .log?), and where do I find it? > Also what backend do you use ? xml, sqlite, mysql or postgresql ? > XML.
Created attachment 370362 [details] Received Error When Attempting to Open XML Data File on Gnucash 2.7.8
Tracefile instructions: https://wiki.gnucash.org/wiki/Tracefile#Trace_file_on_Windows We don't need screenshots of the Windows crash dialog, thanks. They're not helpful.
Created attachment 370363 [details] Gnucash version that failed to open XML data file.
Contents of the Last Trace file (Gnucash 2.7.8): * 17:57:37 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) * 17:57:45 CRIT <gnc.engine> gnc_uri_get_components: assertion 'uri != NULL && strlen (uri) > 0' failed * 17:57:45 CRIT <GLib> g_ascii_strcasecmp: assertion 's1 != NULL' failed * 17:57:51 CRIT <GLib> g_file_test: assertion 'filename != NULL' failed
The error message suggests an issue with a bad file name. Perhaps your file history entries are corrupt. You can try to start gnucash without having it open a file by default by running gnucash from a windows command prompt (cmd.exe) like this: "c:\Program Files(x86)\gnucash\bin\gnucash.exe" --nofile Does this open gnucash successfully ? If so, use Ficheiro->Abrir... to open your data file and see what happens. Does it fail to open the file ? Will it open any other files (still start with copies to be safe!) If it does open your file, what happens if you quit gnucash and restart the program. Does it open the file correctly now ? And then finally, can you retry "Save As..." (Gravar como...) ?
Hmm, there should be a space between Files and (x86) like so: "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --nofile
(In reply to Geert Janssens from comment #7) > The error message suggests an issue with a bad file name. Perhaps your file > history entries are corrupt. > I did a new installation on a VM that had never received Gnucash before, I believe there is no history. > You can try to start gnucash without having it open a file by default by > running gnucash from a windows command prompt (cmd.exe) like this: > "c:\Program Files(x86)\gnucash\bin\gnucash.exe" --nofile > > Does this open gnucash successfully ? > After this my first installation the gnucash usually opened "blank", with no files open (there was no open file history) so I believe this test would not be necessary. > If so, use Ficheiro->Abrir... to open your data file and see what happens. > > Does it fail to open the file ? Will it open any other files (still start > with copies to be safe!) > This is what I did before and it is in this action that the error occurs and does not open anything else because Gnucash crash and closes. > If it does open your file, what happens if you quit gnucash and restart the > program. Does it open the file correctly now ? > > And then finally, can you retry "Save As..." (Gravar como...) ? > No files have been opened because the crash/closes is repetitive in every subsequent attempt. Gnucash installs and opens normally (blank), the problem occurs when you try to open a data file using File->Open.
(In reply to Geert Janssens from comment #8) > Hmm, there should be a space between Files and (x86) like so: > > "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --nofile This does not cause problems with version 2.6.19 that I currently use in my production environment.
What's the full file name of the file you try to open ? I wonder whether this is a locale issue (where gnucash assumes utf-8 characters where they are not). Can you also run "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug to generate a more detailed trace file and attach it here (you will probabaly have to compress it). For the record, I have tried setting the Regional settings on my Windows 7 box to Portuguese (Brazil) and Portuguese (Portugal) and in both case my book opened fine. That assumes from the language in your screenshots you are using a Portuguese locale of course. I'll add I don't have any special characters in my path names hence my first question.
(In reply to GTI from comment #9) > > And then finally, can you retry "Save As..." (Gravar como...) ? > > > No files have been opened because the crash/closes is repetitive in every > subsequent attempt. > > Gnucash installs and opens normally (blank), the problem occurs when you try > to open a data file using File->Open. Somehow I missed this list remark. For clarity, which file are you trying to open ? Your original file that was never opened in gnucash 2.7.x ? Or the one you resaved at some point ? If it is the resaved version, what happens if you open the original file (which you suggested you did successfully in your first message)?
(In reply to Geert Janssens from comment #11) > What's the full file name of the file you try to open ? > D:\Desktop\HBVM.gnucash I tried also D:\HBVM.gnucash unsuccessful. > I wonder whether > this is a locale issue (where gnucash assumes utf-8 characters where they > are not). > Possibly. In the installer I noticed strange characters. > Can you also run > "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug to generate a more > detailed trace file and attach it here (you will probabaly have to compress > it). > Done.
Created attachment 370415 [details] Debug Trace File
(In reply to Geert Janssens from comment #12) > > For clarity, which file are you trying to open ? Your original file that was > never opened in gnucash 2.7.x ? Or the one you resaved at some point ? > My original file that was never opened in gnucash 2.7.x, a actual copy of my XML data file that I normally use in v2.6.19 and the same (Of course, updated and larger) used in the first msg of this Bug Report.
(In reply to Geert Janssens from comment #11) > For the record, I have tried setting the Regional settings on my Windows 7 > box to Portuguese (Brazil) and Portuguese (Portugal) and in both case my > book opened fine. > Here a first-level developer would conclude that the problem is isolated and occurs only with me. It is a great pleasure to work with a high-level developer, in a humble gesture of gratitude, I did some more small tests: The same thing happens in my VMs systems W10 RS, W10 RS2 and of course, W10 RS3, I have other systems (and names! :) but I believe it is enough. Except the W10 RS3 (It's almost virgin! ;), all are "suffered", heavily customized, attacked and altered by viruses.
Geert's away for a week, so I'll barge in. Your log shows it crashing while loading a transaction, which I guess is no surprise. It explains why Geert hasn't been able to reproduce the problem; there's a transaction in your file that gets munged during the save in 2.7 and that make GnuCash crash. Have you tried running GnuCash from a command prompt? CMD or Powershell will both work... the idea is that sometimes programs will write errors to a controlling shell that go off to outer space when run from the GUI. Since you have a ton on VMs, do you happen to have a Linux one, or do you have Mingw-w64 or Cygwin installed anywhere? Either would allow you to run GnuCash under gdb and get a stack trace, which would help a lot in diagnosing the problem. As with bug 793768 you could diff the two files and see if anything pops out. If all of this is beyond your technical comfort point you could zip up both files and send them to me at "jralls at ceridwen dot us" or stick them on dropbox or google drive and send me the link.
(In reply to John Ralls from comment #17) > there's a transaction in your file that gets munged during the save in 2.7 > and that make GnuCash crash. > This is not important but I did not understand "save in 2.7" since the data file was not even opened, how could it be saved, maybe an internal conversion from 2.6 to 2.7 made in the process of opening the file. > Have you tried running GnuCash from a command prompt? CMD or Powershell will > both work... the idea is that sometimes programs will write errors to a > controlling shell that go off to outer space when run from the GUI. > Yes, I used "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --nofile and "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug as Geert suggested and as I have already reported, did not work. > Since you have a ton on VMs, do you happen to have a Linux one, or do you > have Mingw-w64 or Cygwin installed anywhere? Either would allow you to run > GnuCash under gdb and get a stack trace, which would help a lot in > diagnosing the problem. > > As with bug 793768 you could diff the two files and see if anything pops out. > > If all of this is beyond your technical comfort point you could zip up both > files and send them to me at "jralls at ceridwen dot us" or stick them on > dropbox or google drive and send me the link. > I'm sorry, I have many VMs but not all and all I have are Windows. I've worked on other systems but I feel visually more comfortable on Windows.
(In reply to GTI from comment #18) > (In reply to John Ralls from comment #17) > > there's a transaction in your file that gets munged during the save in 2.7 > > and that make GnuCash crash. > > > This is not important but I did not understand "save in 2.7" since the data > file was not even opened, how could it be saved, maybe an internal > conversion from 2.6 to 2.7 made in the process of opening the file. Um, the original report says that GnuCash master can open a file saved by 2.6.x, but after master saves it, it will fail to load the file. When you retested on 2.7.7 GnuCash crashed instead of reporting the file unreadable. Do I misunderstand the problem? Has it changed since the original report?
(In reply to GTI from comment #18) > (In reply to John Ralls from comment #17) > > Have you tried running GnuCash from a command prompt? CMD or Powershell will > > both work... the idea is that sometimes programs will write errors to a > > controlling shell that go off to outer space when run from the GUI. > > > Yes, I used "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --nofile and > "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug as Geert suggested > and as I have already reported, did not work. Ah, you did indeed say that. So my question is "was there any additional output to the command window when you did that?"
(In reply to GTI from comment #18) > (In reply to John Ralls from comment #17) > > Since you have a ton on VMs, do you happen to have a Linux one, or do you > > have Mingw-w64 or Cygwin installed anywhere? Either would allow you to run > > GnuCash under gdb and get a stack trace, which would help a lot in > > diagnosing the problem. > > > > As with bug 793768 you could diff the two files and see if anything pops out. > > > > If all of this is beyond your technical comfort point you could zip up both > > files and send them to me at "jralls at ceridwen dot us" or stick them on > > dropbox or google drive and send me the link. > > > I'm sorry, I have many VMs but not all and all I have are Windows. > I've worked on other systems but I feel visually more comfortable on Windows. OK. Are you willing to trust me with your data so that I can analyze the problem in more depth? I won't share it and I'll delete it as soon as I've resolved the problem.
(In reply to John Ralls from comment #19) > > Um, the original report says that GnuCash master can open a file saved by > 2.6.x, but after master saves it, it will fail to load the file. When you > retested on 2.7.7 GnuCash crashed instead of reporting the file unreadable. > Do I misunderstand the problem? Has it changed since the original report? > Yes, it has changed since comment 2. You confirmed my suspicions. The v2.6.99 (in 2017-05-03) opened the data file saved by the stable version of the time, saved it and corrupted it, so it was no longer possible to reopen it with v2.6.99 which was the last one. The v2.7.8 (in 2018-03-30) does not even open the data file saved by v2.6.19, of course, not the data file corrupted by the old v2.6.99 (See the answers to Geert about this data file).
(In reply to John Ralls from comment #20) > (In reply to GTI from comment #18) > > (In reply to John Ralls from comment #17) > > > Have you tried running GnuCash from a command prompt? CMD or Powershell will > > > both work... the idea is that sometimes programs will write errors to a > > > controlling shell that go off to outer space when run from the GUI. > > > > > Yes, I used "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --nofile and > > "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug as Geert suggested > > and as I have already reported, did not work. > > Ah, you did indeed say that. So my question is "was there any additional > output to the command window when you did that?" > Nope.
(In reply to John Ralls from comment #21) > > OK. Are you willing to trust me with your data so that I can analyze the > problem in more depth? I won't share it and I'll delete it as soon as I've > resolved the problem. > I had already anticipated this and I was afraid of this question and already thought of an alternative. My data file has sensitive personal information and is under SHA-256 encryption and can expose my security. I'm sorry, if I send it to you I'll have to kill you. Not worth the risk, do you? Let's look for alternatives. I will try to generate a dummy data file that can reproduce the problem!
OK, but that may be more difficult than you think unless you can isolate the transaction that's failing in your primary file.
(In reply to John Ralls from comment #25) > > OK, but that may be more difficult than you think unless you can isolate the > transaction that's failing in your primary file. > Once again you are correct. I have tested other files and all have opened so far, including testing v2.6.19 on the W10 RS3 and it works. Everything points strongly to this data file along with v2.7.8. I handle other languages and an immediate workaround would be to use Gnucash in languages that it works on, but this is not the purpose here. I thought about asking the language community that Gnucash failed for help. Please think of something that might help.
I'm not at all convinced that it's related to language or locale, especially since it's a hard crash. I think the simplest thing for you to do is to set up a Mingw-w64 environment and try running GnuCash under the debugger. One pretty simple way to do that is to download https://github.com/Gnucash/gnucash-on-windows/blob/master/setup-mingw64.ps1 and run it. At the end of its installation it will tell you how to start a shell. Do that and in the shell run pacman -S gdb Once that's installed run gdb /c/Program\ Files\ \(x86\)/gnucash/bin/gnucash At the gdb prompt type r<return> GnuCash will load and when it crashes type at the gdb prompt bt<return> (<return> means the return/enter key) Copy all of the output from gdb and paste it into a file, then attach the file here. You can quit gdb with q<return> and exit the msys2 shell with <control>d, but it would be best if you leave gdb running so that I can ask you to collect some more information from it once I've seen the error and the stack trace.
(In reply to John Ralls from comment #25) > > OK, but that may be more difficult than you think unless you can isolate the > transaction that's failing in your primary file. > I have 5 tons of transactions and Gnucash does not even allow you to delete two transactions at a time, so finding the transaction by trial and error proved to be an impossible task. The cause of the error seems to be in the data or the structure of some transaction because I was able to import my chart of accounts with no problems.
Yeah, date would be my first guess. I mentioned bug 793768 yesterday; in his case it's a missing GncEntry date-posted, but he doesn't have a hard crash. You could edit a copy the file in your favorite editor after saving it with compression (Preferences>General) disabled. Just be sure to remove balanced tags (<gnc:transaction> to </gnc:transaction>).
(In reply to John Ralls from comment #27) > > I'm not at all convinced that it's related to language or locale, especially > since it's a hard crash. > > I think the simplest thing for you to do is to set up a Mingw-w64 > environment and try running GnuCash under the debugger. One pretty simple > way to do that is to download > https://github.com/Gnucash/gnucash-on-windows/blob/master/setup-mingw64.ps1 > and run it. At the end of its installation it will tell you how to start a > shell. Do that and in the shell run > pacman -S gdb > > Once that's installed run > > gdb /c/Program\ Files\ \(x86\)/gnucash/bin/gnucash > > At the gdb prompt type > r<return> > > GnuCash will load and when it crashes type at the gdb prompt > bt<return> > > (<return> means the return/enter key) > > Copy all of the output from gdb and paste it into a file, then attach the > file here. > > You can quit gdb with q<return> and exit the msys2 shell with <control>d, > but it would be best if you leave gdb running so that I can ask you to > collect some more information from it once I've seen the error and the stack > trace. > Well, I did, but there were errors and nothing happened at the end. Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine Unrestricted These are the first error: PS D:\Desktop> d:\Desktop\setup-mingw64.ps1 Downloading c:\\gcdev64\\downloads\msys2.exe from http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe Installing c:\\gcdev64\\downloads\msys2.exe --script c:\\gcdev64\input.qs get-item : Não é possível localizar o caminho 'HKCU:\SOFTWARE\Microsoft\HTML Help Workshop' porque ele não existe. No D:\Desktop\setup-mingw64.ps1:159 caractere:17 + ... talled_hh = get-item -path "hkcu:\SOFTWARE\Microsoft\HTML Help Worksh ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (HKCU:\SOFTWARE\...L Help Workshop:String) [Get-Item], ItemNotFoundExcepti on + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemCommand Downloading c:\\gcdev64\\downloads\\htmlhelp.exe from http://download.microsoft.com/download/0/a/9/0a939ef6-e31c-430f-a3df-dfae7960d564/htmlhelp.exe Installing c:\\gcdev64\\downloads\ Não é possível chamar um método em uma expressão de valor nulo. No D:\Desktop\setup-mingw64.ps1:97 caractere:5 + $proc.waitForExit() + ~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : InvokeMethodOnNull
Created attachment 370460 [details] setup-mingw64 - PS Install errors
Comment on attachment 370460 [details] setup-mingw64 - PS Install errors It's OK, you probably let it time out on installing HTML Help Workshop. No matter, you don't need it for this, but it failing did suppress the instructions for opening MSys2. So here they are: Open the start menu and either find MSYS2 and click or just type "mingw" at it. It should bring up "MSYS2 MinGW 32-bit" and "MSYS2 MinGW 64-bit". Pick the 32-bit one and proceed with installing gdb and crashing GnuCash in it.
(In reply to John Ralls from comment #32) > > Comment on attachment 370460 [details] > setup-mingw64 - PS Install errors > > It's OK, you probably let it time out on installing HTML Help Workshop. No > matter, you don't need it for this, but it failing did suppress the > instructions for opening MSys2. > > So here they are: Open the start menu and either find MSYS2 and click or > just type "mingw" at it. It should bring up "MSYS2 MinGW 32-bit" and "MSYS2 > MinGW 64-bit". Pick the 32-bit one and proceed with installing gdb and > crashing GnuCash in it. > I had already done this in 64-bit and gave the same error (bash: gdb: command not found) :( ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $ pacman -S gdb ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $ gdb /c/Program\ Files\ \(x86\)/gnucash/bin/gnucash bash: gdb: comando não encontrado ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $
Sorry, it's pacman -S mingw-w64-i686-gdb
There's more to fix here :( ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $ pacman -S mingw-w64-i686-gdb ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $ gdb /c/Program\ Files\ \(x86\)/gnucash/bin/gnucash bash: gdb: comando não encontrado
Did you get no output from the first command?
Nothing, what is in Comment 35 is all there is.
That's really odd. It should say something. Hmm. Try pacman -Suu If it says to quit at the end, do so by clicking the close-window X at the top of the terminal window, then restart the shell and run it again.
Same thing, it seems to be dead! I think I'm going to reinstall setup-mingw64.ps1. ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $ pacman -Suu ZEUS@DESKTOP-1TUR5C9 MINGW32 ~ $ gdb /c/Program\ Files\ \(x86\)/gnucash/bin/gnucash bash: gdb: comando não encontrado
Well, good news! :)) I've been in the C:\gcdev64\downloads folder and installed one by one manually (htmlhelp.exe, innosetup-5.5.9-unicode.exe and msys2.exe), turned off Wdefender, connected on the internet and ... WOW! see log file attachment.
Created attachment 370464 [details] pacman -S mingw-w64-i686-gdb - Output log
Comment on attachment 370464 [details] pacman -S mingw-w64-i686-gdb - Output log Hmmph. https://github.com/Alexpux/MINGW-packages/issues/1729 provides some information on libstdcxx.v6.printers. You can try moving aside /c/gcdev64/msys2/mingw32/etc/gdbinit, but based on Alex's comment it's quite possible that the crash is from something else. Looking back over your other log, it looks like some Mingw stuff might not have gotten installed. Now that pacman is behaving itself, run setup-mingw64.ps1 again and see if it pulls in some more.
Created attachment 370467 [details] pacman -S gdb - Output log
Created attachment 370468 [details] MINGW64 - Output Log
Created attachment 370469 [details] MSYS - Output Log
Comment on attachment 370468 [details] MINGW64 - Output Log Aha! Now we're getting somewhere. That increases the likelihood that it's a bad date. Tell gdb catch throw r That should stop where the exception is thrown. When it stops get a bt.
(In reply to John Ralls from comment #42) > Comment on attachment 370464 [details] > pacman -S mingw-w64-i686-gdb - Output log > > Hmmph. > https://github.com/Alexpux/MINGW-packages/issues/1729 provides some > information on libstdcxx.v6.printers. > > You can try moving aside /c/gcdev64/msys2/mingw32/etc/gdbinit, but based on > Alex's comment it's quite possible that the crash is from something else. > I do not have this file (gdbinit) > Looking back over your other log, it looks like some Mingw stuff might not > have gotten installed. Now that pacman is behaving itself, run > setup-mingw64.ps1 again and see if it pulls in some more. > Done. See log file.
Created attachment 370471 [details] setup-mingw64.ps1 and gdb Again - Output Log
Created attachment 370472 [details] MINGW64 - catch throw - r - bt - Output Log
Comment on attachment 370472 [details] MINGW64 - catch throw - r - bt - Output Log Rats. A stack smash. That requires hands-on debugging, we're not going to get any further this way.
I think we're back to hand-editing the data file. Do you know what a binary search is?
(In reply to John Ralls from comment #51) > I think we're back to hand-editing the data file. > > Do you know what a binary search is? > I think so.
See you tomorrow :)
What's the menu for today?
Well, I was about to explain how to do a binary search for the problem transaction by removing half of the transactions at a time and testing on the other half... but then I realized that your tracefile might tell us what transaction caused the problem. Every transaction read tries to write to the log and produces a couple of info messages in the log, so I grepped on one of the messages and counted the number of instances: 16929. *But* it also "scrubs" the data and updates it, and that writes that message plus another one, "get rid of rollback" when it finishes the scrub. There are 8464 instances of that message. 16929 = 8464 * 2 + 1, so it's probably transaction 8465 that's causing the crash. Open the file in GnuCash 2.6. If you're using compression (if you don't know, you probably are), turn it off on Edit>Preferences on the General tab. Save the file to a new name. Open the new file in a text editor and delete transactions 1-8460 and 8470-end. (How you do that depends on the text editor, and the more capable the text editor the easier it will be.) Save to yet another file and try opening that with GnuCash 2.7/3.0. If it crashes, copy those 10 transactions to a file and attach it. If not, we're back to trying binary search.
I use Notepad ++. Something is not right, I counted only 4524 "transaction version" occurrences in the data file.
That's interesting. It suggests that it's going through twice. So try 4230-4240.
(In reply to John Ralls from comment #57) > > That's interesting. It suggests that it's going through twice. > I had already noticed this pattern x2. > > So try 4230-4240. > As I waited, I saw this number (4248) in the log and as I had already noticed that the Crash occurred when the progress bar "load data" from Gnucash was almost at the end, I already did 4248-5 up to 4248 + 5, 11 transactions. It is very close to your suggestion (4230-4240). The result is GnuCash CRASH without the Windows msg. There is a possibility that I have "Weeded" something undue in the data file. I think of "brushing the bits" a bit more to improve the target. What do you think?
That's up to you, but if you want you can just change any embarrassing/compromising descriptions and paste the result here. I can fake up some accounts to go with it and start debugging. I guess the next step is to try loading your data file with those 11 transactions removed but everything else intact and see if it loads OK. No windows error dialog is odd, though. Were you running from the Mingw32 shell?
(In reply to John Ralls from comment #59) > > I guess the next step is to try loading your data file with those 11 > transactions removed but everything else intact and see if it loads OK. > That should have been the first thing I should have done. I deleted one by one of 11 transactions and tested, result: Crash at all times and up to with 0 transaction. At least it's very little or not at all likely to be a problem with the data. Interesting is that in a few times the file opened, I closed and opened it and did not open anymore. I also noticed that these files open normally in v2.6.19, so "Weeded" is discarded. > No windows error dialog is odd, though. Were you running from the Mingw32 > shell? > No, I ran Gnucash direct by clicking on the data file. As shown in the logs, gdb does not run in Mingw32, only in Mingw64.
(In reply to GTI from comment #60) > (In reply to John Ralls from comment #59) > > > > I guess the next step is to try loading your data file with those 11 > > transactions removed but everything else intact and see if it loads OK. > > > That should have been the first thing I should have done. > I deleted one by one of 11 transactions and tested, result: > > Crash at all times and up to with 0 transaction. At least it's very little > or not at all likely to be a problem with the data. Interesting is that in a > few times the file opened, I closed and opened it and did not open anymore. > > I also noticed that these files open normally in v2.6.19, so "Weeded" is > discarded. > > > No windows error dialog is odd, though. Were you running from the Mingw32 > > shell? > > > No, I ran Gnucash direct by clicking on the data file. > As shown in the logs, gdb does not run in Mingw32, only in Mingw64. Hmm. Have you tried creating a new file in 3.0, saving it, and reopening it? How about a new file in 2.6.19 and then opening it with 3.0?
I did not even know it had v3.0, is it the same 2.7?
Yeah, I released it yesterday. There are very few changes from 2.7.8.
Dude! Congratulations on the long awaited 3.0 :) I'm going to drink some shots of Wild Turkey Bourbon to celebrate it and I'm going to test the v3.0!
I'll be really surprised if it's any different. Have you tried with new, empty files? If that crashes we've been chasing wild geese for the last 3 days.
(In reply to John Ralls from comment #65) > I'll be really surprised if it's any different. Have you tried with new, > empty files? If that crashes we've been chasing wild geese for the last 3 > days. > I tested 3.0, it works with another file, but it does not work with my data file with 0 transactions.
(In reply to John Ralls from comment #61) > > Hmm. > Have you tried creating a new file in 3.0, saving it, and reopening it? How > about a new file in 2.6.19 and then opening it with 3.0? > I got a generic data file for testing, I opened it in 2.6.19, I created a transaction in it and saved it then I opened it in 3.0 without error, I created a transaction in it in 3.0, saved it, I opened it in 2.6.19 and everything worked fine.
So we're back to something in your datafile that isn't a transaction, or at least isn't a regular transaction, crashing GnuCash. Can you crash it with --debug --extra and attach the tracefile? You might also try whacking out other bits of the data file until you can get it to load. I'll be away tomorrow, back Thursday, then away until Sunday.
Created attachment 370512 [details] Stack Views
(In reply to John Ralls from comment #68) > > So we're back to something in your datafile that isn't a transaction, or at > least isn't a regular transaction, crashing GnuCash. Can you crash it with > --debug --extra and attach the tracefile? > You say execute "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug --extra ? > You might also try whacking out other bits of the data file until you can > get it to load. > The problem is knowing what can be deleted in the file without breaking the xml structure that Gnucash requires. > I'll be away tomorrow, back Thursday, then away until Sunday. > Ok. This will give us time to get a good idea.
(In reply to GTI from comment #70) > (In reply to John Ralls from comment #68) > > > > So we're back to something in your datafile that isn't a transaction, or at > > least isn't a regular transaction, crashing GnuCash. Can you crash it with > > --debug --extra and attach the tracefile? > > > You say execute "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug > --extra ? Yes, and then compress if necessary and attach the resulting tracefile. Since there aren't any transactions left (unless you have scheduled transactions) the crash should show up in a different way. > > > You might also try whacking out other bits of the data file until you can > > get it to load. > > > The problem is knowing what can be deleted in the file without breaking the > xml structure that Gnucash Always delete balanced pairs of top-level tags and make sure that any guid reference has the matching guid. The bare minimum book has the root account and the default currency. Good luck!
(In reply to John Ralls from comment #71) > > > You say execute "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug > > --extra ? > > Yes, and then compress if necessary and attach the resulting tracefile. > Done. > Since there aren't any transactions left (unless you have scheduled > transactions) the crash should show up in a different way. > > There is no scheduled transaction. Even though you clarified that it was to open the file without transactions. > Always delete balanced pairs of top-level tags and make sure that any guid > reference has the matching guid. The bare minimum book has the root account > and the default currency. > > Good luck! > I thought about deleting all accounts and all rates/prices, something I can do from GnuCash. What about Stack Views? Did it help you?
Created attachment 370513 [details] Trace file - No Transaction --debug --extra
Comment on attachment 370513 [details] Trace file - No Transaction --debug --extra It looks like it's crashing now because there's a posted invoice that can't find its transaction, a possibility that hadn't occurred to me. So remove from the file all of the bills (if there are any) and invoices and retry the transaction tests.
No, I haven't memorized the machine code for GnuCash's ~million lines of C, so the Visual Studio debugger doesn't really tell me anything useful. Thanks for trying, though.
(In reply to John Ralls from comment #75) > > No, I haven't memorized the machine code for GnuCash's ~million lines of C, > hehehe! > so the Visual Studio debugger doesn't really tell me anything useful. Thanks > for trying, though. > It is a pity. This is the contents of the stack, the registers, and the hex addresses and etc. at the time of the crash. Each one with its tools and every monkey on its branch :)
I opened my usual xml data file in v2.6.19, saved a copy in sqlite3, opened this sqlite3 file normally, but very time consuming, in v3.0, I saved in v3.0 a copy in xml, I closed it and opened it in v3.0 and there was "Error when analyzing file". There goes my hopes of migrating to v3.0, me and many, as I saw in the list, we are stuck in v2.6.20/19.
Some problem happened with GnuCash after v2.6.99. I installed http://code.gnucash.org/builds/win32/master/gnucash-2.6.99-2017-04-29-git-1a3595c+-setup.exe and it opens my data file normally.
"2.6.99" wasn't a release. It's the version number set on the master branch since maint was branched off after the release of 2.6.1 until Monday when I merged in 3.0. At some point in the next week we'll juggle the branches and master's version will be 3.999 until we release 4.0. So the significant number in that nightly build is the commit number, 1a3595c. Interestingly it's the same commit with which you opened this thread, so it must be that whatever went wrong happened before that commit, not after... not that more things haven't gone wrong since, of course. It might be instructive to test with the nightlies from 4/21 and 5/4. Right after 5/4 Geert merged his Gtk3 change and it took until September to get the nightlies working again.
(In reply to John Ralls from comment #79) > > Interestingly it's the same commit with which you opened this > thread. > Interestingly? I'll kill your curiosity: It was here in the first post that I took the link and downloaded v2.6.99 to test. :) > so it must be that whatever went wrong happened before that commit, > not after... not that more things haven't gone wrong since, of course. > This gave me a knot in the head, for me seems to be inverted but if for you is correct, okay.
The same tests of comment 77 were made with v2.6.20, and as expected the results were the same. I also installed the perl and nothing has changed. Based on the tests so far (Debug, etc), my best guess is that v3.0 now requires a format of a certain data that v2.6.20 did not require and when v3.0 is going to parse this data it crash. Now finding these data "in the nail" is a big task. I suspect of the invoices.
(In reply to GTI from comment #80) > (In reply to John Ralls from comment #79) > > > > Interestingly it's the same commit with which you opened this > > thread. > > > Interestingly? > I'll kill your curiosity: It was here in the first post that I took the link > and downloaded v2.6.99 to test. :) > > > so it must be that whatever went wrong happened before that commit, > > not after... not that more things haven't gone wrong since, of course. > > > This gave me a knot in the head, for me seems to be inverted but if for you > is correct, okay. Two bugs, I guess: One that caused your file not to load, but no crash. That one happened before 1a3595c. Another one that causes GnuCash to crash was introduced after that. The afore-mentioned bug 793768 was from 2.7.4. Why don't you D/L that and see which behavior you get (i.e. crash or error box)?
(In reply to John Ralls from comment #82) > > Two bugs, I guess: One that caused your file not to load, but no crash. That > one happened before 1a3595c. Another one that causes GnuCash to crash was > introduced after that. > Yeah, I had this same feeling (Two bugs). But as my file loaded with 1a3595c, I can not see why the bug would be before. I tested my current file with the 1a3595c just to see if something happened as my file or with Gnscash after the opening of this report. What exempts my file, my location and my language is that many have the same problem. > The afore-mentioned bug 793768 was from 2.7.4. Why don't you D/L that and > see which behavior you get (i.e. crash or error box)? > Yes, you've already given me a lot of homework and I also have some ideas that I would like to test too. But now I'll drink some shots to relax my ideas.
(In reply to GTI from comment #83) > (In reply to John Ralls from comment #82) > > > > Two bugs, I guess: One that caused your file not to load, but no crash. That > > one happened before 1a3595c. Another one that causes GnuCash to crash was > > introduced after that. > > > Yeah, I had this same feeling (Two bugs). > But as my file loaded with 1a3595c, I can not see why the bug would be > before. > Now after a few shots and reread a description of this report I can see!!! :))
If I might intrude on the discussion, I too have a problem loading my 2.6.19 file in 3.0. The program goes through the startup and then crashes when attempting to load the file. I reviewed the gnucash.trace file which contains two warnings and a critical error. I would appreciate some guidance on how I might correct the problem. I have examined the gnucash.trace file and find one critical error that's probably causing the crash. Any ideas on how I might address this problem? * 21:47:50 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) * 21:48:06 CRIT <GLib> g_file_test: assertion 'filename != NULL' failed * 21:48:10 WARN <GLib-GObject> invalid uninstantiatable type '(NULL)' in cast to 'QofInstance' I have also posted this on the mailing list. My apologies for the duplication.
Harold, that looks like a different problem. Please file a separate bug. Before you do, please run GnuCash from the command line as gnucash --debug --extra Attach the resulting tracefile to your new bug, compressing it first if necessary.
Hi John Ralls, I think I have good news. I was able to isolate the cause of crash with Windows msg: A transaction with the empty description field allowed by v2.6.20 produces crash with Windows msg in v3.0, without this bad transaction, we have crash without Windows msg (Only GnuCash crash msg) reinforcing my suspicions here on Comment 81.
OK, that should be easy to fix, but that returns us to the "unable to parse the file" error, right?
It's Done! I think the news is very good! It seems that one more suspicion has been confirmed on Comment 81: After deleting certain invoices to match the integrity of the data file, GnuCash 3.0 has stabilized and works as a charm. Now it looks like all the Bugs are gone, including the original of this report. I think it's up to you now, Sir. John Ralls.
Created attachment 370644 [details] Gnucash Crash mgs Without Windows msg or something like that!
Comment on attachment 370644 [details] Gnucash Crash mgs Without Windows msg or something like that! That sure looks like the Portuguese version of "GnuCash has asked to terminate in an unusual way" to me.
(In reply to GTI from comment #89) > It's Done! > > I think the news is very good! > > It seems that one more suspicion has been confirmed on Comment 81: > > After deleting certain invoices to match the integrity of the data file, > GnuCash 3.0 has stabilized and works as a charm. > > Now it looks like all the Bugs are gone, including the original of this > report. > > I think it's up to you now, Sir. John Ralls. Good news indeed. But I need to understand the changes you made to your file so that I can figure out what about it was causing GnuCash to fail to parse it. I understand that one problem was with a description field. You said it was empty, but was it really empty (<description></description>) or missing altogether (no <description> tag)? IIUC that got you to the "error parsing the file" message. What further changes did you make to resolve that? Simply deleting the invoice(s) that referenced that one transaction? I think it would help if you could post the XML for the affected records before making the changes, perhaps with a diff showing the changes you made.
(In reply to John Ralls from comment #91) > Comment on attachment 370644 [details] > Gnucash Crash mgs Without Windows msg or something like that! > > That sure looks like the Portuguese version of "GnuCash has asked to > terminate in an unusual way" to me. > If you were able to reproduce the Bug? Then, God Save the Queen (Sex Pistols, of course!)
(In reply to John Ralls from comment #92) > > Good news indeed. But I need to understand the changes you made to your file > so that I can figure out what about it was causing GnuCash to fail to parse > it. > I think we can forget the "error parsing the file" because this was caused by me because the data file had not been edited (In the text editor) correctly and coherently (Invoices without your transactions or incomplete tag). > I understand that one problem was with a description field. You said it was > empty, but was it really empty (<description></description>) or missing > altogether (no <description> tag)? > This was really empty (<description></description>). > IIUC that got you to the "error parsing the file" message. What further > changes did you make to resolve that? Simply deleting the invoice(s) that > referenced that one transaction? > Yes, YUC. I deleted the invoices that no longer had their transactions, as my test data file was reduced to 6 transactions that had no invoices, all invoices were deleted. > I think it would help if you could post the XML for the affected records > before making the changes, perhaps with a diff showing the changes you made. > The only changes made were deletions, ie with bad transaction + Invoices = Crash, no bad transaction and no invoices = No Crash. Bad transaction: <gnc:transaction version="2.0.0"> <trn:id type="guid">c5350db5b4c0b3a39b1a571744fbe0c5</trn:id> <trn:currency> <cmdty:space>ISO4217</cmdty:space> <cmdty:id>USD</cmdty:id> </trn:currency> <trn:date-posted> <ts:date>206-01-02 06:59:00 -0400</ts:date> </trn:date-posted> <trn:date-entered> <ts:date>2016-01-02 16:17:21 -0300</ts:date> </trn:date-entered> <trn:description></trn:description> <trn:slots> <slot> <slot:key>date-posted</slot:key> <slot:value type="gdate"> <gdate>0206-01-02</gdate> </slot:value> </slot> </trn:slots> <trn:splits> <trn:split> <split:id type="guid">cb0f98cff8bf32ca7ea0ce1fcc65757a</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>0/100</split:value> <split:quantity>0/100</split:quantity> <split:account type="guid">97a9fadc1c91d96728caf86a1b78e8ec</split:account> </trn:split> </trn:splits> </gnc:transaction> It looks like you might have issues with dates too. See if the information so far is enough, if you need more I'm at your disposal.
(In reply to John Ralls from comment #91) > > Comment on attachment 370644 [details] > Gnucash Crash mgs Without Windows msg or something like that! > > That sure looks like the Portuguese version of "GnuCash has asked to > terminate in an unusual way" to me. > It's not the same msg and that's not what it says there.
(In reply to John Ralls from comment #92) > > I think it would help if you could post the XML for the affected records > before making the changes, perhaps with a diff showing the changes you made. > Explaining better: With bad transaction and with Invoices = Crash with attachment 370362 [details] (Received Error When Attempting to Open XML Data File on Gnucash 2.7.8) No bad transaction and with invoices = Crash with attachment 370644 [details] (Gnucash Crash mgs Without Windows msg or something like that!). No bad transaction and no invoices = No Crash.
(In reply to GTI from comment #94) > (In reply to John Ralls from comment #92) > > > > Good news indeed. But I need to understand the changes you made to your file > > so that I can figure out what about it was causing GnuCash to fail to parse > > it. > > > I think we can forget the "error parsing the file" because this was caused > by me because the data file had not been edited (In the text editor) > correctly and coherently (Invoices without your transactions or incomplete > tag). > > > I understand that one problem was with a description field. You said it was > > empty, but was it really empty (<description></description>) or missing > > altogether (no <description> tag)? > > > This was really empty (<description></description>). > > > IIUC that got you to the "error parsing the file" message. What further > > changes did you make to resolve that? Simply deleting the invoice(s) that > > referenced that one transaction? > > > Yes, YUC. > I deleted the invoices that no longer had their transactions, as my test > data file was reduced to 6 transactions that had no invoices, all invoices > were deleted. > > > I think it would help if you could post the XML for the affected records > > before making the changes, perhaps with a diff showing the changes you made. > > > The only changes made were deletions, ie with bad transaction + Invoices = > Crash, no bad transaction and no invoices = No Crash. > > Bad transaction: > > <gnc:transaction version="2.0.0"> > <trn:id type="guid">c5350db5b4c0b3a39b1a571744fbe0c5</trn:id> > <trn:currency> > <cmdty:space>ISO4217</cmdty:space> > <cmdty:id>USD</cmdty:id> > </trn:currency> > <trn:date-posted> >>>>>> <ts:date>206-01-02 06:59:00 -0400</ts:date> > </trn:date-posted> > <trn:date-entered> > <ts:date>2016-01-02 16:17:21 -0300</ts:date> > </trn:date-entered> > <trn:description></trn:description> > <trn:slots> > <slot> > <slot:key>date-posted</slot:key> > <slot:value type="gdate"> >>>>>>>> <gdate>0206-01-02</gdate> > </slot:value> > </slot> > </trn:slots> > <trn:splits> > <trn:split> > <split:id type="guid">cb0f98cff8bf32ca7ea0ce1fcc65757a</split:id> > <split:reconciled-state>n</split:reconciled-state> > <split:value>0/100</split:value> > <split:quantity>0/100</split:quantity> > <split:account > type="guid">97a9fadc1c91d96728caf86a1b78e8ec</split:account> > </trn:split> > </trn:splits> > </gnc:transaction> > > It looks like you might have issues with dates too. > > See if the information so far is enough, if you need more I'm at your > disposal. I missed this on my first pass. Yeah, the problem isn't the empty description, it's the bad date. The switch to Boost::Date_Time means that dates earlier than 1400 aren't valid anymore. So you can now fix that date in your original file, either from GnuCash 2.6 or in the text editor, make sure you don't have any other bad dates (Find in GnuCash 2.6 should do the job nicely), and try again to load it in GnuCash 3.0.
(In reply to John Ralls from comment #97) > > So you can now fix that date in your original file, either from GnuCash 2.6 > or in the text editor, make sure you don't have any other bad dates (Find in > GnuCash 2.6 should do the job nicely), and try again to load it in GnuCash > 3.0. > This failed, GnuCash crash again. Come on: I have corrected the dates and just dates in the original data file, I installed v3.0 in my not VM production environment (Let's say so because VM is also production!) And I tested it, Gnucash Crash :( I tested it on the VM and BOOM, this worked, so I started to "to pluck" v3.0 installation in the production environment and ... after renaming saved-reports-2.4.off in C:\Users\user\AppData\Roaming\GnuCash, GnuCash WORKED LIKE A CHARM! Now I'm up to date with v3.0! But without my reports :( This was the fatal shot in the Bugs! This was THE ESSENTIAL(https://www.youtube.com/watch?v=bYnAwMxmaUc) or STEEL in them (https://www.youtube.com/watch?v=gkShwaM2oRk). Done, Bugs Craked Successfully! Now it's up to you John, the community looks forward to v3.1!
Huzzah, at last! Unfortunately I don't think that that will fix bug 793768 because that was just failing to insert a date, not crashing. The reporter there hasn't found his bad date yet. I've pushed a fix, and since bug 794934 covers the saved-reports-2.4 problem, I'll close this as fixed.
Ok! Thank you very much.
For me, replacing the non-ASCII characters with ASCII in the saved-reports-2.4 file made GnuCash work with my custom reports!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=782144. Please update any external references or bookmarks.