After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 635911 - GnuCash crashes out when trying to save-as MySQL
GnuCash crashes out when trying to save-as MySQL
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Backend - SQL
2.3.x
Other Windows
: Normal critical
: ---
Assigned To: Phil Longstaff
Chris Shoemaker
: 624465 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-11-27 09:47 UTC by iwaddo
Modified: 2018-06-29 22:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Trace log after save-as to MySQL crash (727 bytes, text/plain)
2010-11-27 11:31 UTC, iwaddo
Details
output from trace (5.44 KB, text/plain)
2010-11-27 17:25 UTC, iwaddo
Details
Trace fiile from Windows 7 MySQL test (1.12 KB, text/plain)
2010-12-02 18:53 UTC, iwaddo
Details

Description iwaddo 2010-11-27 09:47:54 UTC
I am using 2.3.17 on a Windows 7 32 bit PC with MySQL 5.1.53.

Whenever I try to save as MySQL and press enter after having entered my id and password GnuCash crashes out.

As it crashes without any error messages I am unable to look any further as to the cause.



Windows 7 provides the following details

Problem signature:
Problem Event Name: APPCRASH
Application Name:   gnucash.exe
Application Version:        0.0.0.0
Application Timestamp:      4ce8fdc5
Fault Module Name:  libgncmod-backend-dbi.dll
Fault Module Version:       0.0.0.0
Fault Module Timestamp:     4ce8f78b
Exception Code:     c0000005
Exception Offset:   00001bee
OS Version: 6.1.7600.2.0.0.768.3
Locale ID:  2057
Additional Information 1:   0a9e
Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
Additional Information 3:   0a9e
Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

If I open an XML file, edit a transaction and save the file I get the following in a trace file

*   WARN <qof.engine> [guid_init()] only got 1993 bytes.
The identifiers might not be very random.
*   WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory)

If I open an XML file, edit a transaction and save-as MySQL I get the following in a trace file

*   WARN <qof.engine> [guid_init()] only got 1993 bytes.
The identifiers might not be very random.
*   WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory)

It doesn't seem to add anything to this trace file as it crashes.
Comment 1 Geert Janssens 2010-11-27 11:17:20 UTC
To get some more debugging information could you try to:

* open a terminal window (command prompt ? I'm not sure what I should call in on Windows)
* Start gnucash by typing the following command, including the quotes:

"c:\program files\gnucash\bin\gnucash.exe" --log gnc.backend.dbi=debug

If you installed gnucash in a non-default location, you should adapt the path to the binary accordingly.

After the crash, your trace file should contain a lot more information. Can you attach that file to this bug ?
Comment 2 iwaddo 2010-11-27 11:31:29 UTC
Created attachment 175348 [details]
Trace log after save-as to MySQL crash
Comment 3 Geert Janssens 2010-11-27 11:42:49 UTC
Thanks for the trace file.

It doesn't say much, but it does indicate that the crash already happens somewhere during the attempt to make a connection. It doesn't say why though.

Just to get as much information as possible:
* Do you try to save to an existing db or do you allow gnucash to create the db for you ?
* If you created the db yourself, what encoding is it created in ?
* From your mailing list messages, I read you have created a db user with the proper privileges. Is this user setup with a password (I'm not sure even if mysql can have users without a password, but postgres can, and that is known to not work well with libdbi).
Comment 4 iwaddo 2010-11-27 14:49:16 UTC
Hi, I think I have tried every combination going.

Yes, the user did have a password.  I'm pretty confident the 'user' was working as I was able to create a connection using workbench which allowed to connect.

Also, to address the user problem I tried using root and the root password and I've tried with or without an empty database, though given this is the first time I've created a database using MySQL in this way I could easily be doing something wrong.

Regards
Comment 5 iwaddo 2010-11-27 14:59:14 UTC
Hi, I think I have tried every combination going.

Yes, the user did have a password.  I'm pretty confident the 'user' was working as I was able to create a connection using workbench which allowed to connect.

Also, to address the user problem I tried using root and the root password and I've tried with or without an empty database, though given this is the first time I've created a database using MySQL in this way I could easily be doing something wrong.

Regards
Comment 6 Geert Janssens 2010-11-27 15:09:28 UTC
Ok, thanks.

There is one more piece of valuable debug information you could provide us with the stacktrace extracted via gdb.

Here is how you would generate that stacktrace:
* Download and install gdb (direct link to installer: http://downloads.sourceforge.net/mingw/gdb-6.3-1.exe )
* By default, it will install as c:\mingw\bin\gdb.exe
* From the command line, execute this command (keep the quotes in the command:

c:\mingw\bin\gdb.exe "c:\program files\gnucash\bin\gnucash.exe"

* This will start gdb (a command line tool) and offer you a prompt to type commands.
* Simply type
  run
* and hit enter
* This will start gnucash, while being monitored by gdb.
* Let gnucash crash on it's attempt to connect to mysql.
* type
  backtrace
  to get the requested stacktrace.
* Please attach this trace to this bug as well.

Note: the steps outlined here are a reworked version of the steps found in the wiki under 
http://wiki.gnucash.org/wiki/Windows#Debugging_with_gdb
Most of the steps remain the same. Only the exact step to start gdb is different due to some changes in the startup logic of gnucash somewhere in 2.3.x.
The link has some more tips and useful references to generating useful stacktraces for debugging.
Comment 7 iwaddo 2010-11-27 17:25:26 UTC
Created attachment 175364 [details]
output from trace
Comment 8 Geert Janssens 2010-12-01 17:09:59 UTC
Thanks for your backtrace. It gives a good idea of what is happening.

From investigating it and some code reading I have found a potential issue due to the use of an uninitialized pointer.

I have committed a fix for it in r19901. This should appear in the next nightly build.

Could you download and test it tomorrow and see if it solves the crash ? Thanks.
Comment 9 iwaddo 2010-12-02 08:46:49 UTC
Hi

Firstly, this reports relates to a Ubuntu test, I'm not sure whether it is possible to build 2.3.17 svn r19901 on Windows 7, if it is and someone sends me the instructions I'd be more than happy to try it and repeat the steps that led to the bug in the first place.

I have installed Ubuntu 10.10 onto my KDE 10.10 laptop.
I have built 2.3.17 svn r19901
I have installed MySQL Server and MySql Workbench

I opened a previous GnuCash test file and saved-as MySQL - I accepted the defaults offered and used my root id and password.

I now have a file open in GnuCash that says it is called mysql://root@localhost/gnucash

I have restarted GnuCash and it opens with the mysql file without any poblem.

I have look in MySQL-Workbench and can see an object called GnuCash which has tables in it.

I would call this a success.

Regards

Ian
Comment 10 Geert Janssens 2010-12-02 08:59:41 UTC
Thank you for testing. What you describe indeed is indeed the proper behaviour on Ubuntu.

I'd like to have some test results on Windows 7 also. There's no need to build GnuCash yourself to run this test. The GnuCash build infrastructure creates a Windows installer every night with the latest svn sources.

You can find these installers here:
http://code.gnucash.org/builds/win32/trunk/
Scroll all the way down to find the latest build.

You can test as follows:
* Open your xml file in GnuCash and quit again. This simply ensures that the next time you run GnuCash, it will open by default with the xml file and won't attempt to load your database.
* Then completely delete the gnucash database in workbench. That's important, because not having a pre-existing database is a precondition to trigger the bug.
* Then download and install the most recent nightly build from the link above.
* Open your xml file and save it to mysql.
Comment 11 iwaddo 2010-12-02 10:31:48 UTC
Hi

On a clean Windows 7 install I have just

Installed MySQL Server & Workbench
Installed GnuCash 2.3.17 r19901
Opened my original xml file
Saved my xml file
File saved-as MySQL, using defaults & root id & password

I get the following error

The server at URL mysql://root@localhost/gnucash experienced an error or encountered bad or corrupt data

Sorry, but not sure where to look to see what my fit

Regards
Comment 12 Geert Janssens 2010-12-02 13:53:11 UTC
Thanks for being my testing assistant ;) There's no way I can get this information on my system.

So the crash at least has been fixed. On to figuring out why GnuCash fails to connect. Can you run these steps on Windows 7:

* Make sure the the gnucash db doesn't exist in mysql. You can verify that via workbench.

Then repeat the steps from comment 1, repeated here for your convenience:

* open a terminal window (command prompt ? I'm not sure what I should call it on Windows)
* Start gnucash by typing the following command, including the quotes:

"c:\program files\gnucash\bin\gnucash.exe" --log gnc.backend.dbi=debug

If you installed gnucash in a non-default location, you should adapt the path to the binary accordingly.

After the crash, your gnucash trace file should contain a lot more information. Can you attach that file to this bug ?
Comment 13 Geert Janssens 2010-12-02 14:10:22 UTC
(In reply to comment #12)
> After the crash, your gnucash trace file should contain a lot more information.
> Can you attach that file to this bug ?

Obviously, you shouldn't wait for a crash in this case. Please copy the trace file as it is the moment you get the error message on screen. That is the closest to the problem as possible. If you send me the file after you closed GnuCash, it may have a lot more information that's not needed here.
Comment 14 iwaddo 2010-12-02 18:53:41 UTC
Created attachment 175727 [details]
Trace fiile from Windows 7 MySQL test
Comment 15 Geert Janssens 2010-12-03 11:24:15 UTC
Hmm, the trace file shows the actual error message MySQL returned. This means the call to connect to MySQL was reached successfully, but failed.

Let's try to eliminate some external factors before assuming more bugs in GnuCash:

* Can you try to use '127.0.0.1' as host instead of 'localhost' when saving to mysql ?
* Do you have a firewall enabled on Windows 7 (most likely). Can you temporarily disable it completely and try to save to mysql ?
* What happens if you run GnuCash with administrator privileges ? I'm not sure exactly but I believe you can do this by right-clicking on the GnuCash icon and there should be a menu option in the lines of "Run with administrator privileges" or similar.
* If you did re-enable the firewall for the previous test, can you also try with the firewall disabled ?
Comment 16 iwaddo 2010-12-03 17:58:15 UTC
Hi

It worked first time using 127.0.0.1 instead of localhost

So
I deleted the new SQL database
Checked HOSTS to find that 127.0.0.1 localhost was commented out - so I removed the comment and rebooted the laptop

Now file save-as MySQL works to localhost

Success I believe!!

Out of interest I checcked the HOSTS file on my day-to-day Windows 7 desktop only to find the 127.0.0.1 localhost is also commented out.  I not sure what is supposed to make this change but perhaps it is something we could put a warning about on the file save-as form or somehow test for if file save-as MySQL is selected.

Thank you for your help

Regards
Comment 17 Geert Janssens 2010-12-03 23:15:09 UTC
(In reply to comment #16)
> Hi
> 
> It worked first time using 127.0.0.1 instead of localhost
> 
Great ! I suddenly remembered from another issue that Windows has a weird way of dealing with localhost. It seems to be the cause here as well.

> So
> I deleted the new SQL database
> Checked HOSTS to find that 127.0.0.1 localhost was commented out - so I removed
> the comment and rebooted the laptop
> 
As I understand it, Windows assigns the localhost name to your first network card, so localhost is actually equivalent to your PC's network address by default. Uncommenting the line in HOSTS will override this. I don't know if this has other side effects though. Perhaps other, Windows-only programs may rely on localhost referring to your PC's network address.

127.0.0.1 should be safe to use in all circumstances though.

> Now file save-as MySQL works to localhost
> 
> Success I believe!!
> 
Great !

> Out of interest I checcked the HOSTS file on my day-to-day Windows 7 desktop
> only to find the 127.0.0.1 localhost is also commented out.  I not sure what is
> supposed to make this change but perhaps it is something we could put a warning
> about on the file save-as form or somehow test for if file save-as MySQL is
> selected.
> 
See my note above for my understanding of Windows' use of localhost. I have added an entry in the FAQ to help out others hitting the same problem
http://wiki.gnucash.org/wiki/FAQ#Q:_Windows_with_firewall_enabled_won.27t_let_me_save_as_to_a_MySQL.2FPostgresql_database_on_the_same_machine._What_gives.3F
Comment 18 Geert Janssens 2010-12-04 09:29:09 UTC
*** Bug 624465 has been marked as a duplicate of this bug. ***
Comment 19 John Ralls 2018-06-29 22:48:26 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=635911. Please update any external references or bookmarks.