#161 When loading data, check for recursive accounts

Engine (46)
Tom Edelson

If an existing data file (somehow) contains a recursive account structure -- for example, an account which is, directly its own parent, or indirectly its own ancestor -- then, on attempting to load the file into jGnash 1.x, (*) one sees this error message in the log:

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Caused by: java.lang.StackOverflowError
at jgnash.engine.IDMap.get(IDMap.java:167)
at jgnash.engine.Engine.getAccount(Engine.java:868)
at jgnash.engine.Account.getParent(Account.java:397)
at jgnash.engine.Account.getPathName(Account.java:834)
at jgnash.engine.Account.getPathName(Account.java:837)

(and then the last line is repeated many times).

The visible result in the user interface is that the loading of the file fails. jGnash doesn\'t crash, but the user is left with no data to work with.

It would be better if the data loading could mostly succeed, even if it were necessary (for example) to assign an arbitrary parent to one or more accounts. Also, one would like the messages in the log to be clearer about the source of the problem.

(*) The problem was first noticed in Revision 2081 of the Subversion repository.


  • Tom Edelson

    Tom Edelson - 2010-04-12

    a file containing an account that claims to be its own parent

  • Tom Edelson

    Tom Edelson - 2010-04-12

    a file containing an account that designates one of its children as its parent

  • Tom Edelson

    Tom Edelson - 2010-04-12

    contains an account that designates a grandchild as its parent

  • Tom Edelson

    Tom Edelson - 2010-04-12
    • status: open --> closed
  • Tom Edelson

    Tom Edelson - 2010-04-12

    Fixed 2010-04-09, in the commit which created revision 2119.

    Now attached to this bug: three small jGnash data files which can be used for testing; each demonstrates a different variant of the problem.

    Behavior of the program without the fix: perhaps oddly, these three files do not all produce similar-looking results when you attempt to load them into pre-2119 jGnash (and the results can also vary according to other factors, such as whether any other files had previously been loaded into the same jGnash session).

    Behavior of the program with the fix: relatively uniform across the three types of bad input. A warning message is printed in the log file; it names the first account found in the file which is (or would be) involved in a recursive structure (or the first such account for each recursive structure, if there is more than one). The recursive structure is avoided in the loaded data by making that account a direct child of the root account.

    The three sample files contain XML comments which give more details about the program's behavior on attempting to load them, with and (especially) without the fix.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks