GNOME Bugzilla – Bug 552464
Overflow in saved constants
Last modified: 2008-12-17 23:37:04 UTC
attached please find a file created with gnumeric. On opening to cells that should contain GNM_MAX don't have content and the following criticals are printed: ** (gnumeric:29947): CRITICAL **: gnm_cell_set_expr: assertion `texpr != NULL' failed ** (gnumeric:29947): CRITICAL **: gnm_expr_top_unref: assertion `IS_GNM_EXPR_TOP (texpr)' failed ** (gnumeric:29947): CRITICAL **: gnm_cell_set_expr: assertion `texpr != NULL' failed ** (gnumeric:29947): CRITICAL **: gnm_expr_top_unref: assertion `IS_GNM_EXPR_TOP (texpr)' failed
Created attachment 118812 [details] sample gnumeric file
(gdb) up
+ Trace 206841
1856 gnm_expr_parse_str (expr_start, 1857 parse_pos_init_cell (&pos, cell), 1858 GNM_EXPR_PARSE_DEFAULT, 1859 state->convs, 1860 NULL); 1861 gnm_cell_set_expr (cell, texpr); 1862 gnm_expr_top_unref (texpr); 1863 } else 1864 gnm_cell_set_text (cell, content); 1865 } (gdb) p texpr $1 = (const GnmExprTop *) 0x0 (gdb) p content $2 = 0x8c8c30 "=-1.79769313486232e+308"
$2 converts into +Inf on read.
I fixed the criticals when we encounter an expression we cannot parse. I still need to fix the underlying issue.
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. Note: you should reenter those two values so they'll get saved right the next time around.
Thanks. I will be removing the workaround in analysis-histogram.c
- gnm_expr_new_constant (value_new_float (-1E99))); + gnm_expr_new_constant (value_new_float (-GNM_MAX))); Hmm... This might still cause trouble: 1. It will generate sheets that older Gnumerics cannot read. 2. A long-double-enabled Gnumeric will generate sheets that a regular Gnumeric cannot read. Do we really need such constants there? (And why do we set them as expressions?)
If we want to keep the same counting formulas for the histogram we need to have numbers that represent plus and minus infinity. Avoiding those numbers would be possible but would mean that the counting fformulas have to change depending on location. I think that would be highly undesirable. We could (and probably should) just set the value rather than the expression. Would this make any significant difference with this issue? Now if we had a function that returns the smallest/largest representable number I would prefer using that!
Created attachment 124616 [details] [review] Patch for not needing infinite values This patch does away with the need for infinite values. (I didn't touch the poking of the actual values.) This was not particular painful -- I just moved most of it into a function that it is easier to make copies. I can give you functions to return GNM_MIN, GNM_MAX, and a few other interesting values, but you sample says >=GNM_MAX, so you still won't get the final border right. Why are "to below" etc. part of the format as opposed to column headers, btw.?
H i Morten, As I said in comment #8 I would prefer using the same formulas for counting, but it is clearly more important that we are as compatible with earlier version as possible. So I guess we should go with your patch. Please commit. "to below" is part of a format rather than column headers since there is no space for column heasders: when the bins do not include minf and we want to show a histogram plot we need an additional element in the series of cutoffs. That one ends up hidden where the column header should go... If there were another way to do that I would definitely prefer it since the format is picked up by the column and row charts and is then mangled by the chart engine.