slackware64+kde4: crashes on start / load saved files

[Jack128]

Every time I saved and closed a file, homebank 4.2.1 won't load the file.
The example_file.xhb won't load, either. A segment fault happens, I could read
on terminal. I compiled homebank on Slackware64-current, with libofx-0.9.1 on KDE 4.3.4.

Another Slackware user had the same error ->
http://www.linuxquestions.org/questions/slackware-14/homebank-crashing-on-current-kde-4.4-791001/

Kernel: 2.6.32.7

Best Regards,
Jack.

[Maxime DOYEN (mdoyen)]

Would it be possible to use the gdb debugger to see what the segfault is about ?
gdb homebank
then run
after crash
bt

thanks

[Jack128 (jack128)]

Sure, here it is. Tested with the example_file.xhb

gdb homebank
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-slackware-linux"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/bin/homebank
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
[New Thread 0x7ff8b5548720 (LWP 14843)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff8b5548720 (LWP 14843)]
0x000000000043623c in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y

Best Regards,
Jack.

[Maxime DOYEN (mdoyen)]

I was especially interested in the backtrace (bt) gdb command. Can you backtrace before to quit?

[Jack128 (jack128)]

Sure.

(gdb) bt
#0 0x000000000043623c in ?? ()
#1 0x00007fbdbca5672d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#2 0x00007fbdbca6a31d in ?? () from /usr/lib64/libgobject-2.0.so.0
#3 0x00007fbdbca6b7e8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#4 0x00007fbdbca6bce3 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#5 0x00007fbdbe3f1483 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#6 0x00007fbdbca5672d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#7 0x00007fbdbca6a31d in ?? () from /usr/lib64/libgobject-2.0.so.0
#8 0x00007fbdbca6b7e8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#9 0x00007fbdbca6bb42 in g_signal_emit_by_name () from /usr/lib64/libgobject-2.0.so.0
#10 0x00007fbdbca5672d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#11 0x00007fbdbca6a31d in ?? () from /usr/lib64/libgobject-2.0.so.0
#12 0x00007fbdbca6b7e8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#13 0x00007fbdbca6bce3 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#14 0x00007fbdbe4096ed in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#15 0x00007fbdbca5672d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#16 0x00007fbdbca69c38 in ?? () from /usr/lib64/libgobject-2.0.so.0
#17 0x00007fbdbca6b7e8 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#18 0x00007fbdbca6bce3 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#19 0x00007fbdbe40893d in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#20 0x00007fbdbe4adda8 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#21 0x00007fbdbca5672d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#22 0x00007fbdbca69ffc in ?? () from /usr/lib64/libgobject-2.0.so.0
#23 0x00007fbdbca6b66a in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0
#24 0x00007fbdbca6bce3 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
#25 0x00007fbdbe5b095e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#26 0x00007fbdbe4a6713 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#27 0x00007fbdbe4a7833 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#28 0x00007fbdbe132aec in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#29 0x00007fbdbc59e28b in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#30 0x00007fbdbc5a1a4d in ?? () from /usr/lib64/libglib-2.0.so.0
#31 0x00007fbdbc5a1f7d in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#32 0x00007fbdbe4a7c47 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#33 0x0000000000437341 in ?? ()
#34 0x00007fbdbbf91b6d in __libc_start_main () from /lib64/libc.so.6
#35 0x000000000040fd59 in ?? ()
#36 0x00007fff11eb5638 in ?? ()
#37 0x000000000000001c in ?? ()
#38 0x0000000000000001 in ?? ()
#39 0x00007fff11eb6209 in ?? ()
#40 0x0000000000000000 in ?? ()
(gdb)

Best Regards,
Jack.

[Maxime DOYEN (mdoyen)]

Gaps, It do not help me either.
The Homebank you uses was not manually compiled I suppose, as there is no debugging information in gdb backtrace.
Can you check which version of glib and gtk is installed on your gnu/linux distro ?
Are you able to compile HomeBank manually for testing with full debug ?
In case you can turn the debug by:
- move to the homebank main directory
- type find ./src -name '*.c' | xargs perl -pi -w -e 's/MYDEBUG 1/MYDEBUG 0/g'
- then compile
- then run from a console
- post here the result

try gdb again to see if it is more verbose and include HomeBank debug informaitons.
Thanks.

[Jack128 (jack128)]

I've compiled it myself, with the Slackware-Buildscript
> http://slackbuilds.org/repository/13.0/office/homebank/

gtk+ 1.2.10 (x86_64)
gtk+2 2.14.7 (x86_64)

glib 1.2.10 (x86_64)
glib2 2.18.4 (x86_64)

------------------->

Compiled with your guide: (gdb)

See the attachment.

------------------->

Ps: Your debug-on command > "find ./src -name '*.c' | xargs perl -pi -w -e 's/MYDEBUG 1/MYDEBUG 0/g"
should be so:

find ./src -name '*.c' | xargs perl -pi -w -e 's/MYDEBUG 0/MYDEBUG 1/g

Because, in the source, "#define MYDEBUG 0" is the default. ;)

Best Regards,
Jack.

[Maxime DOYEN (mdoyen)]

The problem is that the backtrace under gdb do not give us the function name (just ??)
And without that information it will be difficult to locate the exact problem.

Please check that you compiled with -ggdb option.
The final purpose is to get rid of ?? in gdb backtrace

[Felix Rubio (felixrubiodalmau)]

Hi Maxime
  This is my first post reporting a bug, so if I am not quite precise just let me know. I have the same problem (homebank segfaults when trying to load a saved file). I have compiled homebank from the source (downloaded today) with -ggdb3. Attached you will find the backtrace for this crash. I am using an updated (today) Debian GNU/Linux, with and updated KDE 4.4.

Thank you

[Maxime DOYEN (mdoyen)]

@Felix,
Thanks this help me further.

It seems that there is an archive assigned to a deleted account (which sould not occur and cause the crash).
Do you have the same problem with the example file ?
Load id, save it, then reload ?
If so post this example file that cause the crash here.

Open your file with a text editor and please check the file version,
<homebank v="0.4">
 it should be 0.4.

Let me know the result of all of this.

[Felix Rubio (felixrubiodalmau)]

Hi Maxime.

 I have done your test, and with the example file everything works OK. I
have checked in my file the file version, and is

<homebank v="0.40000000000000002">

what else can I do?

Thank you :)

Felix

On Tuesday 27 April 2010 13:55:13 you wrote:
> @Felix,
> Thanks this help me further.
>
> It seems that there is an archive assigned to a deleted account (which
> sould not occur and cause the crash). Do you have the same problem with
> the example file ?
> Load id, save it, then reload ?
> If so post this example file that cause the crash here.
>
> Open your file with a text editor and please check the file version,
> <homebank v="0.4">
> it should be 0.4.
>
> Let me know the result of all of this.
>

[Maxime DOYEN (mdoyen)]

So the problem is in your file.

Here is what you can check, 1st you have account entries:
<account key="1" flags.....

=> check that the key is always > 0 and note every key somewhere

then you will check your <fav lines
in it there is some attribute account="1"

=> if there is a value here that is not one of your key account, then let me know.
This is the problem.

Of course I will fix this in the close next v4.3.
But as a workaround, you can just changes these value to an existing one, and your file will probably no more crash.

At last, ave you recently deleted some accont into your homebank file ?

Max.

[Felix Rubio (felixrubiodalmau)]

Hi Maxime
 First of all, thank you very much for your help :) I have checked what
you asked me. All account keys are >0, and all fav lines have account >0
too... but there are some dst_account==0. Can this be the source of the
problem?

Thank you!

Felix

On Tuesday 27 April 2010 22:03:00 you wrote:
> So the problem is in your file.
>
> Here is what you can check, 1st you have account entries:
> <account key="1" flags.....
>
> => check that the key is always > 0 and note every key somewhere
>
> then you will check your <fav lines
> in it there is some attribute account="1"
>
> => if there is a value here that is not one of your key account, then let
> me know. This is the problem.
>
> Of course I will fix this in the close next v4.3.
> But as a workaround, you can just changes these value to an existing one,
> and your file will probably no more crash.
>
> At last, ave you recently deleted some accont into your homebank file ?
>
> Max.
>

[Maxime DOYEN (mdoyen)]

Yes if the paymode="5" for these line, then yes.

Now if that's the case I must understand how this happened !
Let me know if you find paymode="5" for fav with a dst_account="0"

[Felix Rubio (felixrubiodalmau)]

Hi Maxime :)
 this is the line I have with dst_account="0":

 <fav amount="166.66999999999999" account="3" dst_account="0" paymode="4"
flags="6" payee="1" category="4" wording="Pagament cotxe" nextdat e="733895"
every="1" unit="2" limit="1"/>

 Felix

On Wednesday 28 April 2010 13:09:50 you wrote:
> Yes if the paymode="5" for these line, then yes.
>
> Now if that's the case I must understand how this happened !
> Let me know if you find paymode="5" for fav with a dst_account="0"
>

[Felix Rubio (felixrubiodalmau)]

one more question: If I set up an automatic transaction today, to be on 3th
day of every month, and I save, I close the program and I restart it... this
transaction is applied today :s.

Felix

On Wednesday 28 April 2010 13:09:50 you wrote:
> Yes if the paymode="5" for these line, then yes.
>
> Now if that's the case I must understand how this happened !
> Let me know if you find paymode="5" for fav with a dst_account="0"
>

[Maxime DOYEN (mdoyen)]

You have probably set to insert x days into the future in File/Properties ?

[Maxime DOYEN (mdoyen)]

Don't focus on <fav with dst_acount=0
Please check if you have some with paymode=5 and a dst_account, not existing

[Felix Rubio (felixrubiodalmau)]

Hi Maxime

 You were right, I set-up a 30 day to look in the future. It was my
mistake, I am sorry. Thank you very much :-). Related to the
paymode/dst_account, all dst_accounts exist for paymode=5 keys.

Thank you!

Felix

On Wednesday 28 April 2010 22:17:27 you wrote:
> Don't focus on <fav with dst_acount=0
> Please check if you have some with paymode=5 and a dst_account, not
> existing
>

[Maxime DOYEN (mdoyen)]

Fixed for v4.3

[alves (rudsonalves)]

The bug persists in version 4.3.

[David Ondrejkovic (david-ondrejkovic)]

 HELP!!!! Please remove me from the list!!!!!!!! I am too stupid to do
it myself!!!!!!

Dne 17.10.2010 17:33, alves napsal(a):
> The bug persists in version 4.3.
>

[Maxime DOYEN (mdoyen)]

@ alves.
No this bug is fixed, maybe the problem is another one.

You should test into your file with a text editor if you find paymode="5" for fav with a dst_account="0"
(see the previous post here)

Please also do the other test Felix has done in the past and then we will see.

[Maxime DOYEN (mdoyen)]

@david
you have and unsubscribe button on the right, just click !...

[David Ondrejkovic (david-ondrejkovic)]

 I have done it, ut it needs some password which I forgot a long time
ago.......

Dne 18.10.2010 21:55, Maxime DOYEN napsal(a):
> @david
> you have and unsubscribe button on the right, just click !...
>