can you "gdb attach" to your running gnucash process and get a
backtrace of the failure?  Also, what version of gnucash?

gnucash version 1.8.4, the latest stable.

I can attach, but I fear the backtrace is not very useful. I did *not* strip the guile executable. (BTW: there is a focus [keyboard grab] problem doing this: I had to kill the gnucash window after the sigsegv in order to be able to quit gdb!)

bertin    2161   902 24 18:34 pts/4    00:00:09 /usr/local/bin/guile -e main -s /opt/gnucash/libexec/overrides/gnucash

# gdb
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"./home/bertin/.gdbinit:10: Error in sourced command file:
"/home/bertin/core" is not a core dump: File format not recognized

(gdb) attach 2161
Attaching to process 2161
0x2ac78860 in ?? ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x2ad3dfd5 in ?? ()
(gdb) bt

+ Trace 37691

Detaching from program: , process 2161

Ahh, you've got an ancient version of gdb.  Any chance you could
upgrade gdb to version 5.2 or 5.3 and try the attach again?

Thanks!

In the problem you're describing, do you have any non-ascii
characters, e.g. accentuated e or a, or something like that? There are
known problems with international characters in bug#112516 and
bug#112091 .

Also, can you save the data file right before the crash, and does the
crash then occur every time you opened that saved data file? If that
is the case, is there a chance you can post that data file here or
privately to one of our developers?

(Downgrading Severity to Major since compared to the other bugs it
isn't a blocker at all.)

> In the problem you're describing, do you have any non-ascii
> characters, e.g. accentuated e or a, or something like that? There 

No. Actually, I get the same crash when I try to open a ledger from the menu. I think the bug(?) is somewhere in there.

> (Downgrading Severity to Major since compared to the other bugs it
> isn't a blocker at all.)

  Well, it is for me :) I can't get anywhere because of it....

As to upgrading gdb: I can't do that immediately. I remember trying it some time ago, and in the end there was a reason why I didn't go through with it. Is it that much better?

Yes, it is that much better.
It will give you symbols in dlopen()d objects,
so you will get a real stack trace.

running:
./configure --prefix=/opt/gdb-5.x 
make
make install

should be all you need to get a working gdb.

> Yes, it is that much better.
> It will give you symbols in dlopen()d objects,

Ah? But I get those in 5.1.1 too.., at least during a debugging.! (Have to load the object first, of course, but I assume that will not have changed :)).

So I modified my debug wrapper a bit, and now gnucash is launched from within gdb:

> gnucash
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".../home/bertin/.gdbinit:10: Error in sourced command file:
"/home/bertin/core" is not a core dump: File format not recognized

Argument list to give program being debugged when it is started is "-e main -s /opt/gnucash/libexec/overrides/gnucash".
(gdb) r
Starting program: /usr/local/bin/guile -e main -s /opt/gnucash/libexec/overrides/gnucash
[New Thread 1024 (runnable)]
Gdk-WARNING **: locale not supported by C library

[Here I ask to open the general ledger:]
Program received signal SIGSEGV, Segmentation fault.
0x2ad3efd5 in g_list_last () from /usr/lib/libglib-1.2.so.0
(gdb) bt

+ Trace 37738

I'll give gdb 5.3 a shot to see if it gives a more complete backtrace.

So much for that so much better gdb :)

> env GDB=/tmp/gdbbuild/gdb/gdb /opt/gnucash/bin/gnucash
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".../home/bertin/.gdbinit:10: Error in sourced command file:
"/home/bertin/core" is not a core dump: File format not recognized

Argument list to give program being debugged when it is started is "-e main -s /opt/gnucash/libexec/overrides/gnucash".
(gdb) r
Starting program: /home/local/bin/guile -e main -s /opt/gnucash/libexec/overrides/gnucash
[New Thread 1024 (runnable)]

Gdk-WARNING **: locale not supported by C library
[open a general ledger]
Program received signal SIGSEGV, Segmentation fault.

+ Trace 37740

(Gdb is better in that it indeed reads the appropriate symbols when attaching).

I get *exactly* the same backtrace when I attach to a running process, and when I try to open a ledger from an empty window.

Hmm, I find it very odd that it crashes without a real stack trace. 
Something really funky is going on here....

Also, what do you mean "open a ledger from an empty window"?

> Hmm, I find it very odd that it crashes without a real stack
> trace.
> Something really funky is going on here....

  As in Motown? No wonder there's no trace :) 

> Also, what do you mean "open a ledger from an empty window"?

  Sorry, thought that'd be obvious. I closed the account structure I had open (it does have accented characters in it in *some* places) by requesting a new file, and then cancelling the druid. That left me with an empty window. There is still the 'General ledger' command in (OTMH) the Tools menu, and that command is active and crash-prone.

PS: re: blocking or not: ok, let's call it not a blocker. But then I'll rename some files (add an r in the obvious place) ;^]

I'm still trying to reproduce this problem..  I followed your
instructions:

File -> New File
Cancel the druid, leaving an empty window
Tools -> General Ledger

It popped up a ledger window just fine....

Well, I'd hope it would work (not crash) for you; if this were a common problem, I really couldn't understand how this version made it to 'release'! As I said, this really makes it impossible to use the programme for me!

I guess that if one double-clicks (opens) an account in the tree, the ultimate result is that a ledger window opens, no? The fact that I get a crash when opening a ledger in an empty window only prooves that this is not a result of the 'accented character' bug mentioned earlier.

I think there is a problem somewhere with my installation, possibly a compatibility issue. Somewhere, and with all those dependencies, it is not going to be easy to find out where.

Would the crash really occurs in a GLib routine, or would it be the result of something naughty performed before?

Could it have anything to do with the fact that I compiled my whole gnome 1.4.x tree with --disable-nls (I've noticed before that this is not an option that seems to be profoundly tested)?

The --disable-nls could be a problem.  I know it's not at all widely
tested.

It could potentially crash in glib if there were memory corruption
elsewhere.

Is there any way you could just re-install your machine?  Modern
Mandrake ships with gnucash-1.8 pre-built.  You can just install all
the dependencies as RPMs and then you don't have to build anything.

reinstall? No. This machine is too important and too tuned. And too loaded too. Would *you* do that for a programme that you are attempting to evaluate? I'll get a new distribution when I get a new machine....

Well, I did sort of mean re-install gnome + gnucash from mandrake RPMs.
I didn't necessarily mean re-install the whole machine.

All the dependencies you need SHOULD be available in RPM format from
Mandrakesoft...  I would suggest installing all of them instead of
building all of gnome from scratch.

Without being able to reproduce this, and without being able to get a
full stack trace, there is absolutely nothing I can do other that
offer random suggestions of things to try.  This could be a hardware
problem (extremely unlikely)...  But more likely it's a problem with
how you built gnome.

One of the above debug output said "locale not supported by C
library". What locale are you running (i.e. environment variable
LANG)? And just to clarify from my suggestion above: Can you save the
gnucash data to a file (File -> Save As) just before the crash, and
does the crash occur also when you opened that file? If this is the
case, can you submit that gnucash data file here?

Created attachment 17510 [details]
account as imported from Money95bank_fr.qif

Created attachment 17511 [details]
empty account file

> Well, I did sort of mean re-install gnome + gnucash from mandrake
> RPMs.
> I didn't necessarily mean re-install the whole machine.

You know Mandrake. There is no way I could find rpms that work on my machine. At least not before I manually upgrade rpm and probably glibc. And even then: the file structure has changed considerably in the meantime. There is actually more chance I find something edible at redhat, if they still support their 6.0 or 6.1 series.

$LANG and all other nls-related env.vars are unset. To prevent *most* applications from barfing this error message. I don't need nls: I only talk English with my computers and programmes. For some reason, gnome (even the system-original version, 1.0.14) always gives me this message. Probably because I upgraded gtk+ and gdk system-wide, and without nls support.

I attached 2 account files; the one I first discovered the problem with (because I started playing with that one), and an empty account created by the recipe above. With both, I can get the crash.

Let's dig a bit more directly. Is there a way to get guile to dump a backtrace when it receives a (lethal) signal, or if not, is there a way to get it to verbosely print out all statements before executing them, so that I can at least provide you with the sequence leading to the crash? I would hope that at least one of these alternatives is possible...

Ok, thanks for this explanation of an unset LANG (huh, never heard of
that before). What happens if you set LANG=C before you start gnucash?
i.e. does this crash happen just in the same way?

> Ok, thanks for this explanation of an unset LANG (huh, never heard

   Really? I remember the time when noone ever heard of the LANG variable, and when setting had no general predefined effect :)

> of that before). What happens if you set LANG=C before you start
> gnucash? i.e. does this crash happen just in the same way?

   It crashes in the same way, and, abacadabra, I get the same gdk warning.

I just noticed something. When I use the 'open ledger' 'command, I get that warning message another time. What process is being spawned here ('cause I think this is a startup-only warning)?!

same bug here. mandrake 9.1 using whatever comes default. i see a 
guile-1.4.1 crash whenever i double click on an account in the list 
(ie accounts receivable). gnucash 1.8.1. did a full install of 
mandrake 9.1. still there. anyway to trace what is wrong? or get 
packages that work?

FWIW, I just opened your data file and it worked just fine.  I REALLY
think the problem is your machine environment.  Have you tried just
building gnucash from sources (to make sure it matches your machine
environment?)

Derek, to whom were you speaking? I think I made it pretty clear that I *did* build gnucash from the sources (since my very machine environment makes it impossible to use a package :~) ?!

BTW: it is a relief to see that it is not "just me" with my old environment. Of course, 'thepoch' has a Mandrake too...

Well, can you try compiling without --disable-nls?

I already did, in fact before submitting my report. It didn't make a difference. The crash, btw, is in guile...

What makes you think the crash is in guile?  The stack traces you've
shown only show the last two stack frames, and those are in glib. 
That sort of rules out guile, since guile doesn't use glib.  However,
glib is called extensively from all over the place, so without at
least that third stack frame there is no way to figure out where this
is coming from.

I suppose if you're feeling involved you could set a gdb breakpoint at
the 'open account window' function and then single-step through the
code until it crashes....  You could start from, for example,
regWindowLedger
and see how far you get.

Errr... building with debug information requires more free space than I currently have. Sorry...
[I know, I really do need a new system ... :~ ]

Well, then, not much we can do to help you unless someone else
exhibiting this problem can help us debug.

I've poked around a bit, and located an external drive that I should be able to hook up to my system, giving some extra elbow room.

Is there a possibility to run gnucash from the build directory and be sure it uses the local libs etc? I did manage to build gnucash this afternoon, but from what gdb showed me, it looked like I was actually running the installed version...

OK, I found some place (over 350M is needed for the debug-enabled build and install directories!!!).
I had a small hunch this was not going to be easy: with debugging info, gnucash runs just fine.

In my experience, this may mean 2 things.
1) some local variable is not initialised in optimised mode (I have a strong impression that either the -g option or gdb does some form of initialisation in some cases) Or alignment is just sufficiently different to not catch that write-outside-bounds in that one (sub)routine...
2) a part of the code is not correctly compiled with the particular combination of optimisation flags.

It would be interesting to know what flags the binary package was compiled with. If I have time, I may be able to do a build with just -O2 . By default, I use a whole collection of options that are optimal for me, but I know that notably some gnome (image handling) libraries do not work correctly with them. I don't recall having seen crashes, though.

I'm rebuilding again for the Xth... And wondering for the Xth time why it is that I always end up with a whole bunch of .scm files that are symlinked to themselves. This happens in a for loop in a number of makefiles, where ln -sf ${srcdir}/$X . is executed inside ${srcdir}...
Already I prepended a dash (minus) to the for loops so that make wouldn't quit when ln warns of attempting to link a file to itself, but removing the -f option to ln doesn't stop this??!
Am I using a too old version of the fileutils (4.0i)?

BTW: could this bug (not the ln issue ;-)) be caused by -fomit-frame-pointer?

Answer concerning the flags: no. Compiling after configuring with
CC=gcc 'CFLAGS=-O2 -mcpu=pentiumpro -march=pentiumpro'
gives exactly the same crash.
I should maybe try with -O2 -g, but not right away...
BTW: the full set of flags I usually use is (supposing someone might want to play and see if the crash is more repeatable like that):
-fwritable-strings -mcpu=pentiumpro -march=pentiumpro -fno-fast-math -malign-double -fno-float-store -fomit-frame-pointer -mieee-fp -fno-strict-aliasing -I/home/bertin/work/include -I. -I/usr/include/X11 -I/usr/X11R6/include -I/usr/local/include/libpng -I/usr/include/freetype -fdollars-in-identifiers -O3 -fstrength-reduce  -fexpensive-optimizations -frerun-cse-after-loop -fno-schedule-insns -fno-schedule-insns2 -funroll-loops -fno-unroll-all-loops -finline-functions   -Wcomment -Wunused -Winline -Wchar-subscripts -Wparentheses -Wcast-align -Wsurprising -Wsequence-point -Wp,-w -D_PROTOTYPES -D_IEEE -D_LINUX_SOURCE -L/usr/X11R6/lib -L/usr/local/lib

I don't know what else to say here...  I'll leave this bug open in the
hopes that you actually figure out what's going on, but I suspect the
problem is that the binary didn't match your OS, and your rebuild
"fixed" that problem.

But how can the binary not have matched my operating system given that *ALL* versions that I tried were built by me, on my and that same operating system?!

What exactly does the --enable-debug configure flag do? Does it include much extra code, and if so, through what conditional flag (macro)? If I just pass -g via CFLAGS, will that also result in an exploding build directory?

The going-into-hiding of a bug when compiled with gcc -g is alas all too common. There is a number of such bugs that I never explicitly resolved, even in much simpler projects that I wrote myself. I might also try with -lefence, but I don't know how feasible that is given that most of your code are dynamically loaded guile modules. Can one 'override' malloc and family in just a single, dlopen'ed .so library?

All --enable-debug does is add "-g" to CFLAGS and LDFLAGS.

Hey guys, 

I seem to have the same exact problem as RenE although my environment
is a bit different. I'm on Gentoo running gnucash 1.8.4 (complete
system built from source). 

1.8.4 had been working fine for me until I recently upgraded evolution
to 1.4.3. To do this, 5 dependent packages were also upgraded:

- gnome-extra/gal-1.99.8
- /usr/portage/dev-libs/nspr/nspr-4.3.ebuild
- dev-libs/nss-3.8
- gnome-base/ORBit2-2.6.2
- gnome-extra/libgtkhtml-3.0.7

I suspect one of the above upgrades is the culprit.

I've attached a bug buddy trace to help.

BTW, Gnucash is awesome - I enter in every monetary transaction I make
into it. If there is anything I can do to help resolve this bug,
please let me know and I'll try my best! Keep up the great work!

Created attachment 19132 [details]
Bug buddy trace

Did you upgrade libc?  Other than perhaps gal, all the rest of those
packages are gnome2 packages, so should not affect GnuCash at all.  I
suppose nspr and nss aren't gnome2 packages, so they might have
affected you...

Also, can you rebuild gnucash with debugging symbols?  The crash dump
isn't very helpful:

+ Trace 39529

This seems to imply a bug in the "iswlower()" function from libc.

Hmm, now that you mention it... ;) Just reveiwed my emerge.log and I
did do an update just before updating evo that brought in a new
version of glibc - from 2.3.1 to 2.3.2.

Still working on a trace with symbols...

I built gnucash with -g as mentioned above in my CFLAGS but received
the same stack trace via bug buddy. Is there a command that I can use
to verify that the binary has symbols?

After work I'll try to attach via gdb.

Honestly, I dont know how to test that short of running "file" on the
various objects (there isn't a single binary -- it's a bunch of modules).

After much tinkering, I finally figured out that the Gentoo's portage
system was the one stripping the gnucash debug symbols. BTW, found a
good way to test for them too ('file' always said symbols weren't
stripped for some reason - i guess function name symbols were still
present):

  readelf -w /usr/lib/gnucash/libgncmod-register-gnome.so.0.0.0

Hopefully this backtrace will be more useful. Thanks.

Created attachment 19165 [details]
Backtrace with debug symbols

While attached to gnucash, even before the crash, calling iswlower seg
faults:

(gdb) call iswlower('a')
 
Program received signal SIGSEGV, Segmentation fault.
0x4024e418 in wctype_table_lookup () from /lib/libc.so.6
The program being debugged was signaled while in a function called
from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (iswlower) will
be abandoned.
(gdb) 

Definitely sounds like a environmental issue. I'll try to figure it
out. Thanks for the help Derek! 

I wrote a small program to test iswlower and strangely it doesn't crash. 

#include <wctype.h>
#include <stdio.h>

int main() 
{
  if (iswlower('a'))
    printf("is lower!");

  getchar();
}


I attached to it with gdb, and call'ed iswlower. It works there too:

GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu".
(gdb) attach 30655
Attaching to process 30655
Reading symbols from /home/phase/development/misc/a.out...done.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x400ecf58 in read () from /lib/libc.so.6
(gdb) call iswlower('a')
$1 = 1
(gdb)

I wonder what would make iswlower crash under guile but not under my
test program? Looks like they are both using the same /lib/libc.so.6
 

I rebuilt glibc and gnucash works now. Not sure exactly what happened.
Not a gnucash problem for me at least. Thanks again for the advice, Derek!

 

From what the last comments read, this bug can probably be closed (NOTABUG or
similar) soon.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=114932. Please update any external references or bookmarks.