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 338400 - hangs upon replaying a (somewhat) longer log file
hangs upon replaying a (somewhat) longer log file
Status: VERIFIED INCOMPLETE
Product: GnuCash
Classification: Other
Component: Import - Other
1.8.x
Other All
: Normal critical
: ---
Assigned To: Christian Stimming
Christian Stimming
Depends on:
Blocks:
 
 
Reported: 2006-04-13 23:10 UTC by Scott Engles
Modified: 2018-06-29 21:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Scott Engles 2006-04-13 23:10:12 UTC
Steps to reproduce:
1. startup with an account file left from a recent crash of gnucash :-), which
is not difficult to obtain :-( 
2. File -> Import -> replay log file
3. select the log file that was being written at the time of the crash


Stack trace:


Other information:
Version is 1.8.12.  My data file is large (over 20 MB) with probably 15,000
transactions in it.  The hang is real.  I've waited hours for it to come back. 
It bounces around the account window changing the values in fields for the
various accounts, like "present", "future", "cleared", and "reconciled".  In the
original hang it did this for over an hour before I killed the process.
Then I went in to the .log file and edited out all the entries that were present
PRIOR to my most recent save.  Restart and replay.  This time it finished with
the bouncing around the window (after a long time), and then just sat there.  I
left it there for almost three hours, and it was still hung.  Kill, edit the log
file to just a few entries, and lo and behold, it worked, albeit pretty slow for
such a small amount of retrieved information (I think it was the clearing of
three or four splits, no new transactions...).  So I tried it with more of the
log file, just over 200 lines worth of entries.  It took forever (more than an
hour), during which I started this bug report.
As I was typing, that particular replay completed.  So perhaps the replay
process is just incredibly slow.  And this was for just a handful of
transactions.  It would have been exponentially faster to re-enter these
transacions by hand than to retrieve them in this fashion.
I will leave my bug report as a hang, because after waiting hours with no
feedback and no window refresh, any reasonable person would conclude that the
process was completely hung.
Comment 1 Scott Engles 2006-04-13 23:13:14 UTC
My machine is not all that slow:  Mobile Sempron 2600 (64 bit) with 1 GB RAM.  I am running the 32 bit version of Fedora Core 5.
Comment 2 Christian Stimming 2006-04-28 08:48:18 UTC
I'm sorry to hear these problems that you encountered with gnucash. Just for clarification: The "hang" happens with gnucash-1.8.12, doesn't it? Do you have tested this with any 1.9.x/SVN version? Because the development on 1.8.x has stopped and we won't fix anything there anymore, as the 2.0.0 release is scheduled for mid-May.
Comment 3 Scott Engles 2006-05-02 16:48:24 UTC
Yes, I have only been running 1.8.12; I can't say about 1.9.x.

It seems that the log file replay is limited to recording and changing transactions only.  If one has renamed or moved accounts within the tree, added scheduled transactions, edited accounts (eg. adding some notes), tax information, or perhaps just about anything else, that this information is not logged.  Therefore, in the event of a crash which separates the entry of all this work from the saving of it, it will all be lost regardless of the log file.

This limits the usefulness of log files (in addition to the incredible length of time it was taking to replay them, if the replay EVER finished); and means that unless you save frequently, you can still lose a lot of work if gnucash, or your computer, crashes.  But I suppose that would be a different bug :-)

Scott
Comment 4 Christian Stimming 2006-08-11 09:36:10 UTC
In response to comment#3: The limited usefulness is described in bug#150514 and bug#340361, feel free to add more info there if needed. As for the original problem with a very slow log file replaying: Could you please verify whether this is still a problem with 1.9.x/2.0.x? Thank you very much.
Comment 5 Christian Stimming 2006-09-04 11:35:23 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 6 John Ralls 2018-06-29 21:01:32 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=338400. Please update any external references or bookmarks.