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 709329 - Budgets API allows setting value for period greater than num_periods
Budgets API allows setting value for period greater than num_periods
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Budgets
2.4.x
Other All
: Normal minor
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2013-10-03 02:04 UTC by R Ratliff
Modified: 2018-06-29 23:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix Bug 709329 (2.96 KB, patch)
2013-10-03 02:06 UTC, R Ratliff
reviewed Details | Review
Fix bug 709329 (2.95 KB, patch)
2013-10-23 19:07 UTC, R Ratliff
needs-work Details | Review
Fix off-by-one error and remove dependency on g_test_expect_message (4.35 KB, patch)
2013-10-24 21:02 UTC, R Ratliff
committed Details | Review

Description R Ratliff 2013-10-03 02:04:49 UTC
In gnc-budgets.c, it is possible to set a budget value for a period that is greater than the number of periods in the budget.
Comment 1 R Ratliff 2013-10-03 02:05:22 UTC
This may be a feature, not a bug. It is my understanding that the code stores the budget values in a hash table (correct me if I'm wrong).
Comment 2 R Ratliff 2013-10-03 02:06:21 UTC
Created attachment 256338 [details] [review]
Fix Bug 709329

Unit tests included.
Comment 3 Geert Janssens 2013-10-18 15:30:56 UTC
Review of attachment 256338 [details] [review]:

Thank you for your patch.

I note that you added a FIXME indicating there is no error reporting if the check fails. I would like to see some error reporting added.

How much depends on how this bug can be triggered.

Note that I haven't studied the budgetting code. I'm working on principle here.

Can a user do something to get into the situation that this test fails ? Like if setting a wrong value for an option somewhere can lead to this check failing, then the user should get a visual feedback (gnc_error_dialog or something like that).

If the bug is rather academic and can be triggered only by calling the function with values that in normal use of the program don't happen, you could write a warning in gnucash.trace (using PWARN()).

I'll leave it to you to investigate this a bit further :)
Comment 4 R Ratliff 2013-10-23 19:07:26 UTC
Created attachment 257959 [details] [review]
Fix bug 709329

Geert, you are right, this is an academic bug. I couldn't find or think of any situations where it would be triggered by normal use in the UI. 

I've updated the code to throw a PWARN and then return. The unit test is updated to expect this warning, using g_test_expect_message.
Comment 5 John Ralls 2013-10-24 00:20:54 UTC
(In reply to comment #4)
> The unit test is
> updated to expect this warning, using g_test_expect_message.

That API is too new: We're still using 2.28 as the minimum required version of GLib. Please use the message handling API in src/test-core/unittest-support.h.
Comment 6 Geert Janssens 2013-10-24 07:38:09 UTC
Comment on attachment 257959 [details] [review]
Fix bug 709329

Change patch status as per John's comment.
Comment 7 R Ratliff 2013-10-24 20:27:18 UTC
I also noticed that in my first two patches I had an off by one bug in the engine code. num_periods starts from 1, but period_num starts from 0. When I do the if statement to see if the error should be thrown, I should do the following:

if (period_num >= GET_PRIVATE(budget)->num_periods)
Comment 8 R Ratliff 2013-10-24 21:02:49 UTC
Created attachment 258058 [details] [review]
Fix off-by-one error and remove dependency on g_test_expect_message

The code was changed to use g_test_log_set_fatal_handler. Then it uses g_assert_cmpint (check.hits, ==, 1);
to assert that the handler was actually called.

Here's the source code for that specific section:

+    oldlogger = g_log_set_default_handler ((GLogFunc)test_null_handler, &check);
+    g_test_log_set_fatal_handler ((GTestLogFatalFunc)test_checked_handler, &check);
+    gnc_budget_set_account_period_value(budget, acc, 12, gnc_numeric_create(100,1));
+    g_assert_cmpint (check.hits, ==, 1);
+    g_log_set_default_handler (oldlogger, NULL);


As a side note, if you apply this patch and run make check, the check fails because of a failing unit test in /engine/Transaction. But if you check the history, you will see that this test (/engine/Budget/gnc_budget_set_account_period_value) passes.
Comment 9 Geert Janssens 2013-10-26 08:57:24 UTC
Comment on attachment 258058 [details] [review]
Fix off-by-one error and remove dependency on g_test_expect_message

Committed are r23335. Thank you very much !
Comment 10 Geert Janssens 2013-10-26 08:58:05 UTC
(In reply to comment #7)
> I also noticed that in my first two patches I had an off by one bug in the
> engine code. num_periods starts from 1, but period_num starts from 0. When I do
> the if statement to see if the error should be thrown, I should do the
> following:
> 
> if (period_num >= GET_PRIVATE(budget)->num_periods)

Since this is easily missed while working on the code, I have added a comment right above the test.
Comment 11 Geert Janssens 2013-10-26 08:58:15 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 12 John Ralls 2017-09-24 22:41:04 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 13 John Ralls 2018-06-29 23:19:42 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=709329. Please update any external references or bookmarks.