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 640962 - Make check failure: test_backend_dbi - g_unlink(./test-dbi.xml.LCK): 2: No such file or directory
Make check failure: test_backend_dbi - g_unlink(./test-dbi.xml.LCK): 2: No su...
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Backend - SQL
git-master
Other Linux
: Normal normal
: ---
Assigned To: John Ralls
Geert Janssens
Depends on:
Blocks:
 
 
Reported: 2011-01-30 18:37 UTC by Christoph Holtermann
Modified: 2018-06-29 22:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Unsuccessful fix (1.78 KB, patch)
2011-01-30 18:37 UTC, Christoph Holtermann
needs-work Details | Review

Description Christoph Holtermann 2011-01-30 18:37:18 UTC
Created attachment 179645 [details] [review]
Unsuccessful fix

Taking care of the localization problem of libdbi (see https://bugzilla.gnome.org/show_bug.cgi?id=611936) partially breaks the python-bindings. I tried the things in the attached patch which do not match the goal of making them work. Just to show what doesn't work. In hope of someone who understands more of this than i do.
Comment 1 Christoph Holtermann 2011-01-30 18:54:17 UTC
(In reply to comment #0)
> Created an attachment (id=179645) [details] [review]
> Unsuccessful fix
> 
> Taking care of the localization problem of libdbi (see
> https://bugzilla.gnome.org/show_bug.cgi?id=611936) partially breaks the
> python-bindings. I tried the things in the attached patch which do not match
> the goal of making them work. Just to show what doesn't work. In hope of
> someone who understands more of this than i do.

What actually happens is that they compile fine and work for xml as far as i
see but execution of scripts breaks for mysql and sqlite3 with this error msg:

python: symbol lookup error: /usr/lib/gnucash/libgncmod-backend-dbi.so: undefined symbol: gnc_push_locale
Comment 2 Christian Stimming 2011-02-01 09:18:19 UTC
Comment on attachment 179645 [details] [review]
Unsuccessful fix

Instead of app-utils, you need core-utils now (since r20214)
Comment 3 Geert Janssens 2013-05-23 09:48:14 UTC
I came across this bug by chance while looking for patches with "needs-work" status.

I tried to make the python bindings fail by accessing an sqlite3 file, but it seems I can't. I don't see the error message you mention in comment 1.

Can you still reproduce this or can the bug be closed ?
Comment 4 Christoph Holtermann 2013-05-25 12:16:20 UTC
(In reply to comment #3)
> I came across this bug by chance while looking for patches with "needs-work"
> status.
> 
> I tried to make the python bindings fail by accessing an sqlite3 file, but it
> seems I can't. I don't see the error message you mention in comment 1.
> 
> Can you still reproduce this or can the bug be closed ?

Thank you for having a look at this. 
It has been a while and I`m trying to reproduce. 
With gnucash svn rev 23000 and libdbi-0.9 freshly installed and having the patch applied compiling and running gnucash with my usual mysql-scenario works fine. 
I also enabled sqlite+sqlite3 in libdbi ( ./configure --with-sqlite --with-sqlite3 --with-mysql ) which I hadn't been able to get running before - I never really tried to solve that issue for me because I only use MySql - and I am now able to open and write sqlite3 files with gnucash - fine !

The only thing I get is 

/usr/local/lib/dbd/libdbdsqlite.so: undefined symbol: sqlite_encoding
libdbi: Failed to load driver: /usr/local/lib/dbd/libdbdsqlite.so

when running gnucash ( starts anyway ) or scripts and it breaks make check.

make[5]: Entering directory `/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test'
TEST: test-backend-dbi... (pid=21757)
/usr/local/lib/dbd/libdbdsqlite.so: undefined symbol: sqlite_encoding
libdbi: Failed to load driver: /usr/local/lib/dbd/libdbdsqlite.so
  /backend/dbi/store_and_reload/sqlite:                                
(/usr/local/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:21757): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): 2: No such file or directory
FAIL

This seems to be only an issue for sqlite2 -> I disable that one.

making libdbi-drivers without sqlite:
./configure --with-sqlite3 --with-mysql

error persists, I seem to have to clean up the previous make of libdbi-drivers more thoroughly -> sudo rm /usr/local/lib/dbd/libdbdsqlite.* - doesn't work.

./configure --with-sqlite --with-sqlite3 --with-mysql
make; sudo make uninstall;

./configure --with-sqlite3 --with-mysql
make clean; make; sudo make install
recompile gnucash

-> gnucash works fine, python skripts I tested work fine

make check fails.

make[5]: Entering directory `/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test'
TEST: test-backend-dbi... (pid=20262)
  /backend/dbi/store_and_reload/sqlite:                                
(/usr/local/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:20262): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): 2: No such file or directory
FAIL
GTester: last random seed: R02S0603e0cc5942936e3da5a0da2d44499e
/bin/sh: Zeile 1: 20261 Beendet                 MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) gtester --verbose test-backend-dbi

-> I will try some more - it seems as if the original problem is indeed closed - I am gonna spend some time on this the next few days and will write again.
Comment 5 Christoph Holtermann 2013-05-25 15:32:33 UTC
Error in test-backend-dbi.c
occurs when calling g_test_run( );

file: src/backend/xml/gnc-backend-xml.c
function xml_session_end
tried some Variations of message that leads to segfault:
Lines 403...

PWARN("Error on g_unlink(%s)", be->lockfile);
PWARN("Error on g_unlink %d", errno);
PWARN("Error on g_unlink %s", g_strerror(errno) ? g_strerror(errno) : "");
PWARN("Error on g_unlink(%s): : %s", be->lockfile, g_strerror(errno) ? g_strerror(errno) : "");
PWARN("Error on g_unlink(%s): %s: %d", be->lockfile, g_strerror(errno) ? g_strerror(errno) : "", errno);
PWARN("Error on g_unlink %d (%s): %s", errno, be->lockfile, g_strerror(errno) ? g_strerror(errno) : "");
PWARN("Error on g_unlink(%s): %d: %s", be->lockfile, errno, g_strerror(errno) ? g_strerror(errno) : "");

The last line is the original one. All Variations work fine. Only errno in the middle leads to segfault. Funny.

I put gdb in the skript test-backend-dbi in func_exec_program_core like this

(echo r ; echo backtrace; cat) | gdb --args "$progdir/$program" ${1+"$@"}

BTW I wonder where this autoquitting in gdb behavior comes from

the resulting output:
  /backend/dbi/store_and_reload/sqlite3:
(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK)
<FATAL WARNING> (gnc.backend) [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK)

(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink 2
<FATAL WARNING> (gnc.backend) [xml_session_end()] Error on g_unlink 2

(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink No such file or directory
<FATAL WARNING> (gnc.backend) [xml_session_end()] Error on g_unlink No such file or directory

(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): : No such file or directory
<FATAL WARNING> (gnc.backend) [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): : No such file or directory

(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): No such file or directory: 2
<FATAL WARNING> (gnc.backend) [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): No such file or directory: 2

(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink 2 (./test-dbi.xml.LCK): No such file or directory
<FATAL WARNING> (gnc.backend) [xml_session_end()] Error on g_unlink 2 (./test-dbi.xml.LCK): No such file or directory

(/mounts/UserSpace/home/christoph/Computer/src/gnucash/gnucash_svn/gnucash/src/backend/dbi/test/.libs/test-backend-dbi:24771): gnc.backend-WARNING **: [xml_session_end()] Error on g_unlink(./test-dbi.xml.LCK): 2: No such file or directory

Program received signal SIGSEGV, Segmentation fault.
__strcmp_ssse3 () at ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:233
233             cmpb    %cl, (%edx)
(gdb) #0  __strcmp_ssse3 () at ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:233
  • #1 g_strcmp0
    at gtestutils.c line 1976
  • #2 test_checked_handler
  • #3 g_logv
  • #4 g_log
  • #5 xml_session_end
    at gnc-backend-xml.c line 409
  • #6 qof_session_end
    at qofsession.c line 1499
  • #7 teardown
    at utest-backend-dbi-basic.c line 50
  • #8 test_case_run
    at gtestutils.c line 1673
  • #9 g_test_run_suite_internal
    at gtestutils.c line 1716
  • #10 g_test_run_suite_internal
    at gtestutils.c line 1727
  • #11 g_test_run_suite_internal
    at gtestutils.c line 1727
  • #12 g_test_run_suite_internal
    at gtestutils.c line 1727
  • #13 g_test_run_suite
    at gtestutils.c line 1772
  • #14 g_test_run
    at gtestutils.c line 1320
  • #15 main
    at test-backend-dbi.c line 60

So there seems to be a bug in glib testutils. I found a possible duplicate
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=513014
something in g_strcmp0

But all this doesn't seem to be related to the original question ;-)
Comment 6 Geert Janssens 2013-05-25 16:12:28 UTC
Thanks for all the feedback. FWIW I experience the same make check failure on my Fedora 18 (32-bit) system. I did already inquire on the gnucash-devel list if others are seeing this, but so far there's no reply.

Since you have provided a great deal of details about this failure to this bug, I'm going to do something unusual and repurpose it to follow up on the make check failure. That saves you from having to repost all the data in a new bug ;)
Comment 7 John Ralls 2013-05-25 17:33:33 UTC
> So there seems to be a bug in glib testutils. I found a possible duplicate
> https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=513014
> something in g_strcmp0

No, that's silly. g_strcmp0 isn't part of testutils, it's a rewrite of POSIX
strcmp that's safe to pass NULL to... but it's not safe to pass a non-zero but
still invalid pointer.

Geert, sorry I forgot about your crash report on the dev list. I built the 2.5.1 release a few days later and didn't see a problem (on Debian Wheezy). I have an F18 VM, so I'll do the trial distcheck for 2.5.2 there and report back.
Comment 8 Christoph Holtermann 2013-05-25 19:46:21 UTC
Ok, fine, repurposed. Further debugging results:

a) PWARN("Error on g_unlink(%s): %d: %s", "TEST1", 2, "TEST2"); segfaults too
b) PWARN("Error on g_unlink(%d): %s: %s", 2, "TEST1", "TEST2"); works fine

I found the problem is connected to test_checked_handler in unittest-support.c
test_checked_handler (const char *log_domain, GLogLevelFlags log_level,
                      const gchar *msg, gpointer user_data )

it is being called by
masquerade_fatal = fatal_log_func && !fatal_log_func (log_domain, test_level, msg, fatal_log_data);

in a)
Breakpoint 3, test_checked_handler (log_domain=0xb706ec28 "gnc.backend", log_level=18, msg=0x809fef0 "[xml_session_end()] Error on g_unlink(TEST1): 2: TEST2", user_data=0xbfffe360) at unittest-support.c:115
115         TestErrorStruct *tdata = (TestErrorStruct*)user_data;
(gdb) print log_domain
$1 = 0xb706ec28 "gnc.backend"
(gdb) print log_level
$2 = 18
(gdb) print msg
$3 = (const gchar *) 0x809fef0 "[xml_session_end()] Error on g_unlink(TEST1): 2: TEST2"
(gdb) print user_data
$4 = (gpointer) 0xbfffe360
(gdb) s
117         if ((tdata == NULL)
(gdb) print tdata
$5 = (TestErrorStruct *) 0xbfffe360
(gdb) print tdata->log_domain
$6 = (gchar *) 0x2 <Address 0x2 out of bounds>

in b)
Breakpoint 2, test_checked_handler (log_domain=0xb706ec28 "gnc.backend", log_level=18, msg=0x8101260 "[xml_session_end()] Error on g_unlink(2): TEST1: TEST2", user_data=0xbfffe360) at unittest-support.c:115
115         TestErrorStruct *tdata = (TestErrorStruct*)user_data;
(gdb) l
110
111     gboolean
112     test_checked_handler (const char *log_domain, GLogLevelFlags log_level,
113                           const gchar *msg, gpointer user_data )
114     {
115         TestErrorStruct *tdata = (TestErrorStruct*)user_data;
116
117         if ((tdata == NULL)
118                 || (tdata->log_domain != NULL
119                     && g_strcmp0 (tdata->log_domain, log_domain))
(gdb) print user_data
$1 = (gpointer) 0xbfffe360
(gdb) s
117         if ((tdata == NULL)
(gdb) print tdata
$2 = (TestErrorStruct *) 0xbfffe360
(gdb) print tdata->log_domain
$3 = (gchar *) 0xb706eddd "TEST1"
(gdb) s
118                 || (tdata->log_domain != NULL
(gdb) s
119                     && g_strcmp0 (tdata->log_domain, log_domain))

It seems to be a wrong assignment. test_checked_handler treats user_data as
TestErrorStruct. user_data is va_list args1 that was argument to g_logv.
It seems to be rather coincidence that b does not crash ;-)
Comment 9 Christoph Holtermann 2013-05-25 19:52:55 UTC
I think I will it leave this one from here on because I don't really understand the logic of fatality ;-) and why THIS functions outputs the messages at THIS point (and if it is always called for output or just during make check or during fatal ( why is this situation fatal ? the log level in the call to g_logv has been WARNING ). I want get back in the direction of the original question -> Why is this ./test-dbi.xml.LCK not found ? and -> is the original question solved or not ;-) ?
Comment 10 John Ralls 2013-05-25 21:36:25 UTC
It's fatal because g_test_init() sets all warnings and criticals to fatal.
test_checked_handler is set as a log error handler to test for another message... but it should be removed again before teardown() is called, so that's a bit strange.

The absence of the lock file is caused by setup() calling qof_session_begin() with ignore_lock = TRUE, which causes xml_session_begin() to skip creating -- or even checking for -- the lock. When qof_session_end() comes around and wants to
clear the  lock, it isn't there, so there's a warning.

Based on your latest debugging, memory's getting stomped in there somewhere: The tdata is passed in to test_checked_handler as a separate struct and should be independent of the string that PWARN passes to g_log().

> is the original question solved or not?

I don't know. Neither Geert nor I could reproduce it. Can you?
Comment 11 Christoph Holtermann 2013-05-25 22:00:31 UTC
Not yet ;-) I guess it's fixed. I dug into these other bug aspects today - I'm interested how the database architecture works because for my python - latex - invoice script I need the name of the owner of the database and address and so on which are not yet being covered by the python bindings ( at least some time ago they weren't ). Actually I'm up to that. But that just by the way. From my side: Close the original bug. If I somehow happen to get to reproduce it I will tell and it can be reopened. But I don't believe that will happen.
Comment 12 John Ralls 2013-05-25 22:09:15 UTC
OK. I've figured out what's going on with the error message and have a good idea why it crashes on you and Geert. I even have an idea on how to make it not crash the test, which I'll commit shortly.
Comment 13 John Ralls 2018-06-29 22:53:02 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=640962. Please update any external references or bookmarks.