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 641832 - Crash opening MySQL database after installing 2.4.2 over 2.4.0
Crash opening MySQL database after installing 2.4.2 over 2.4.0
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Backend - SQL
2.4.x
Other Windows
: Normal critical
: ---
Assigned To: Phil Longstaff
Geert Janssens
Depends on:
Blocks:
 
 
Reported: 2011-02-08 12:41 UTC by Bruce Leary
Modified: 2018-06-29 22:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GCB Stack Trace created with BT FULL (14.66 KB, text/plain)
2011-02-08 15:36 UTC, Bruce Leary
Details
GDB stack trace (4.34 KB, text/plain)
2011-02-08 17:53 UTC, Ian K
Details
Backtrace for 2.4.2 trying to connect to MySQL (5.31 KB, text/plain)
2011-02-08 22:19 UTC, Mark Sansom
Details

Description Bruce Leary 2011-02-08 12:41:13 UTC
Installed 2.4.2 over 2.4.0 and it crashes when trying to open MySQL database.  It will open a GnuCash file.  Reverted to 2.4.0 and it runs fine.

OS is Windows Vista 32 SP2 with current patches.

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	gnucash.exe
  Application Version:	0.0.0.0
  Application Timestamp:	4d4fd144
  Fault Module Name:	msvcrt.dll
  Fault Module Version:	7.0.6002.18005
  Fault Module Timestamp:	49e0379e
  Exception Code:	c0000005
  Exception Offset:	0000eb50
  OS Version:	6.0.6002.2.2.0.768.3
  Locale ID:	1033
  Additional Information 1:	8b0c
  Additional Information 2:	572b0da015ad26d8b5b370b85ec7793e
  Additional Information 3:	faa1
  Additional Information 4:	9da72459c951dc11491de57cd3b329cd

Read our privacy statement:
  http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409
Comment 1 Ian K 2011-02-08 13:31:37 UTC
I get this with Sqlite database too.
"Unhandled Win32 exception occurred in GnuCash.exe [3060]"
Windows Xp Pro Sp3, Gnucash 2.4.2
Can load up XML database into 2.4.2, but also get the same crash if I try to 'Save as' Sqlite file
Comment 2 Christian Stimming 2011-02-08 15:02:05 UTC
Any chance you can create a stack trace http://wiki.gnucash.org/wiki/Stack_Trace ? Thanks!
Comment 3 Bruce Leary 2011-02-08 15:36:09 UTC
Created attachment 180392 [details]
GCB Stack Trace created with BT FULL
Comment 4 Ian K 2011-02-08 17:53:07 UTC
Created attachment 180400 [details]
GDB stack trace
Comment 5 Ian K 2011-02-08 17:56:05 UTC
My stack trace event is from within GnuCash creating new file, saving to Sqlite3:
File > New File
Select GBP as currency
Select Common Accounts
Apply
Save As... > Sqlite3, filename test
Comment 6 John Ralls 2011-02-08 19:58:33 UTC
Comment on attachment 180400 [details]
GDB stack trace

This looks like a bad libdbi: It's crashing while parsing the query format. Christian, is it possible that msvcrt doesn't like one of the format codes, or that there's a compatibility problem between the msvcrt on your system and the one on this user's system?
Comment 7 Christian Stimming 2011-02-08 20:58:31 UTC
I can imagine very well this to be some issue with the scanf/printf format strings. On windows, it is vital to use glib's macros for format specifiers, similar to those I've added in r20161: e.g. G_GINT64_FORMAT instead of "%lld" (to be more specific: Instead of "lld", the "%" is still separate). This might be wrong inside libdbi as well, and then it crashes.

On the other hand, this error might get triggered through our new libdbi sanity check only, and this check can be disabled on G_OS_WIN32 because there we know we ship a correct libdbi. (Sort of.)
Comment 8 John Ralls 2011-02-08 21:25:56 UTC
Look at the stack trace. It's crashing during the call which inserts the test record into the table, while parsing those glib macros you added in r20161.
Comment 9 Christian Stimming 2011-02-08 21:32:07 UTC
Do you imply the glib macros in r20161 might be wrong? Well, without them I got compiler errors on my 64bit system, but to be precise I'm indeed not completely sure whether all of those were necessary according to the compiler errors.
Comment 10 Mark Sansom 2011-02-08 22:19:49 UTC
Created attachment 180427 [details]
Backtrace for 2.4.2 trying to connect to MySQL
Comment 11 Mark Sansom 2011-02-08 22:21:24 UTC
Attachment above shows the dbg output from 2.4.2 on my system (Win 7 x64) trying to connect to a MySQL database on my Windows Home Server.  GC crashes and it seems to be related to strlen()....

Program received signal SIGSEGV, Segmentation fault.
0x751043df in strlen () from C:\Windows\syswow64\msvcrt.dll
Comment 12 John Ralls 2011-02-08 22:38:57 UTC
Calm down. I don't know what's wrong, I just know from the stack trace what line of code is crashing.

But, I just noticed this (actually, I noticed it before but just understood what it's telling me) in the first stack trace:
>      doublestr = "1.7976921348623158e+307\000hd\"\000`P�v`\003\027\006\t\000"
MSWin uses 32-bit wchars, IIRC, so the terminal 8-bit \0 termination supplied by g_ascii_dtostr isn't sufficent to terminate the string once it bubbles through to msvcrt. I can add a memset() to zero out that buffer, but it's possible that the other parts of the format are having similar issues. 

The other places in the sql code where there are G_INT64_FORMAT conversions, Phil did the conversions locally and passed the result to dbi_conn_query() instead of asking dbi_conn_queryf() to do the formatting. Maybe I should do the same here.
Comment 13 Christian Stimming 2011-02-09 08:01:11 UTC
(In reply to comment #12)
> The other places in the sql code where there are G_INT64_FORMAT conversions,
> Phil did the conversions locally and passed the result to dbi_conn_query()
> instead of asking dbi_conn_queryf() to do the formatting. Maybe I should do the
> same here.

This sounds like a good idea. Not because I would understand this issue more deeply, but just from empirical evidence that the previous code apparently didn't crash on windows but this new code has problems (or triggers them somewhere else).
Comment 14 Krypto Man 2011-02-10 02:00:20 UTC
I experienced this same problem with a PostgreSQL 9.0 database. Running on 32 bit Windows 7.
Comment 15 SHIINA, Hideaki 2011-02-10 06:24:11 UTC
My GnuCash2.4.2 crashes too, when connect to MySQL5.1.49-community on Win7 64bit Ultimate.  GnuCash2.4.0 didn't crash at same case.
Comment 16 Krypto Man 2011-02-11 00:06:51 UTC
Now that lots of people are likely using database back ends for GnuCash, this seems like a big enough bug to pull the 2.4.2 release (or at least post a warning on the download page to not install if you are using a database backend).
Sorry, bugzilla probably not the best place to post this sort of comment but don't see any other communication channel available.

Thanks for a really useful product. I have reverted to 2.4.0 and things are working again.
Comment 17 Geert Janssens 2011-02-12 10:49:56 UTC
(In reply to comment #16)
> Now that lots of people are likely using database back ends for GnuCash, this
> seems like a big enough bug to pull the 2.4.2 release (or at least post a
> warning on the download page to not install if you are using a database
> backend).
> Sorry, bugzilla probably not the best place to post this sort of comment but
> don't see any other communication channel available.
> 
> Thanks for a really useful product. I have reverted to 2.4.0 and things are
> working again.

I'm not sure if "lots of people" are already using the sql backend, but you are surely right the issue should be announced. I have added a warning in the news section on the main GnuCash page. That is also the page most people will use to download GnuCash, so it should have a fairly good coverage.
Comment 18 Christian Stimming 2011-02-12 17:31:05 UTC
As a first workaround on windows, I've disabled the test_dbi_library() altogether in r20287. This should at least get rid of the crash in version 2.4.3.
Comment 19 John Ralls 2011-02-12 19:03:08 UTC
Um, OK. I finally got a windows build to finish last night, verified the crash, added the memset, and... it failed to build. A simple "make" doesn't in windows because the linker paths aren't encoded in the makefiles. No wonder Phil cross-compiles on Linux. At that point it was bedtime.

Anyway, I'll get that sorted today and see if the problem is the string termination thing, the libdbi formatting, or something else. If it's something else, I'll have to figure out how to get GDB working on MinGW, I guess.
Comment 20 John Ralls 2011-02-12 20:17:09 UTC
Well, neither change prevents the crash, so it's off to getting gdb working in msys.
Comment 21 John Ralls 2011-02-13 20:03:46 UTC
Turns out that's wrong. It's a problem with dbi_conn_queryf(). When I format the string with g_strdup_printf and submit it to dbi_conn_query(), it doesn't crash.

r20295.
Comment 22 Helge 2011-02-23 05:56:18 UTC
(In reply to comment #0)
> Installed 2.4.2 over 2.4.0 and it crashes when trying to open MySQL database. 
> It will open a GnuCash file.  Reverted to 2.4.0 and it runs fine.
> 
> OS is Windows Vista 32 SP2 with current patches.
> 
> Problem signature:
>   Problem Event Name:    APPCRASH
>   Application Name:    gnucash.exe

I'm experiencing this crash since several older versions including 2.4.0 using OS Windows7-64. The same versions did work fine on OS Windows XP-32.
I wonder if anyone was "ever" able to successfully open or save at MYSQL using Windows7-64 for older GnuCash versions?
This might help you guys to trace the root cause of the problem.
Comment 23 Geert Janssens 2011-02-23 13:56:00 UTC
I can imagine you experience "a" crash in versions before 2.4.2, but "this" crash can only happen as of 2.4.2, simply because the code that causes this crash wasn't included before 2.4.2.

John effectively traced the root cause of this crash and applied a fix in svn revision 20295 (that's what comment 21 mentioned). There may be other crasher bugs not yet reported before though.

Can you try and install a more recent nightly build which can be downloaded from here:
http://code.gnucash.org/builds/win32/trunk/

If you still experience a crash with a more recent nightly build, I would like to ask you to open a new bug report and add some details, like the GnuCash trace file and optionally a gdb stacktrace.
Comment 24 John Ralls 2018-06-29 22:53:22 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=641832. Please update any external references or bookmarks.