GNOME Bugzilla – Bug 649901
CRITICAL **: gnm_go_data_get_expr: assertion `dep != NULL' failed
Last modified: 2011-05-13 15:52:45 UTC
Created attachment 187579 [details] sample file open the attached file and save. This yields ** (gnumeric:26291): CRITICAL **: gnm_go_data_get_expr: assertion `dep != NULL' failed ** (gnumeric:26291): CRITICAL **: gnm_go_data_get_expr: assertion `dep != NULL' failed This could be an ODF export/import or a charting issue.
gdb says:
+ Trace 227071
No valgrind events. FWIW: (gdb) p (char *)g_type_name_from_instance (dat) $7 = 0x62ea07 "GODataScalarVal" (gdb) p go_data_serialize (dat, (void*)0) $8 = 0x6dd930 "9"
The issue is that we can't assume that a GOData has an associated GnmDependent. gog_axis_set_bounds creates simple scalar data.
Created attachment 187594 [details] [review] Proposed patch
I don't like putting such tests in openoffice-write.c We could teach gnm_go_data_get_expr to return NULL in the absence of a dep.
Created attachment 187595 [details] [review] New patch We can just remove the critical.
For the purpose that we are using it in openoffice-write here, just removing the critical would be the fine. Elsewhere it might be more useful if in the case of simple scalar data we would return an expression representing that data.
> Elsewhere it might be more useful if in the case of simple scalar data we would > return an expression representing that data. I thought of that, but current API doesn't return a ref.
gnm_go_data_get_expr is in Gnumeric, so why are we restricted by API?
> gnm_go_data_get_expr is in Gnumeric, so why are we restricted by API? We're not -- beyond "then it's more work".
Jean, I think you should commit your patch of comment 6 ("just remove the critical") When we run into a place where it would be useful to have it return even scalar data as a texpr, we can make any other changes then.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. At least there is no more critical.