Bug 347916 – Entering =[] causes CRITICAL

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 347916 - Entering =[] causes CRITICAL


Summary:	Entering =[] causes CRITICAL


Status:	RESOLVED FIXED

Product:	Gnumeric
Classification:	Applications
Component:	General
Version:	1.7.x
Hardware:	Other All

Importance:	Normal normal
Target Milestone:	---
Assigned To:	Jody Goldberg
QA Contact:	Jody Goldberg

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2006-07-18 13:38 UTC by Carsten Clark
Modified:	2006-07-21 19:42 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Carsten Clark 2006-07-18 13:38:15 UTC

Steps to reproduce:
1. Enter the formula =[] or any other formula containing left and right brackets.
2. Upon entering the ']', the following is printed on the console before crash:
** (gnumeric:28012): CRITICAL **: go_url_encode: assertion `*text != '\0'' failed


Stack trace:
(gdb) run
Starting program: /Users/cdc6d/local/bin/gnumeric 
Reading symbols for shared libraries ......+++.+++++...........................................++++++++++++++ done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done

** (gnumeric:28012): CRITICAL **: go_url_encode: assertion `*text != '\0'' failed

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x900030e8 in strlen ()
(gdb) where

+ Trace 69418

#0 strlen
#1 go_url_resolve_relative
at go-file.c line 295
#2 gnm_app_workbook_get_by_name
at application.c line 395
#3 wbref_parse
at parse-util.c line 836
#4 rangeref_parse
at parse-util.c line 1000
#5 gnm_expr_expr_find_range
at gnumeric-expr-entry.c line 668
#6 gnm_expr_entry_can_rangesel
at gnumeric-expr-entry.c line 1214
#7 cb_entry_changed
at gnumeric-expr-entry.c line 230
#8 g_closure_invoke
#9 signal_emit_unlocked_R
#10 g_signal_emit_valist
#11 g_signal_emit_by_name
#12 gtk_entry_real_insert_text
#13 g_closure_invoke
#14 signal_emit_unlocked_R
#15 g_signal_emit_valist
#16 g_signal_emit_by_name
#17 gtk_entry_insert_text
#18 gnm_canvas_commit_cb
at gnumeric-canvas.c line 670
#19 g_closure_invoke
#20 signal_emit_unlocked_R
#21 g_signal_emit_valist
#22 g_signal_emit_by_name
#23 g_closure_invoke
#24 signal_emit_unlocked_R
#25 g_signal_emit_valist
#26 g_signal_emit_by_name
#27 gtk_im_context_simple_commit_char
#28 gtk_im_context_simple_filter_keypress
#29 gnm_canvas_key_press
at gnumeric-canvas.c line 510
#30 _gtk_marshal_BOOLEAN__BOXED
#31 g_closure_invoke
#32 signal_emit_unlocked_R
#33 g_signal_emit_valist
#34 g_signal_emit
#35 gtk_widget_event_internal
#36 gtk_window_propagate_key_event
#37 gtk_window_key_press_event
#38 _gtk_marshal_BOOLEAN__BOXED
#39 g_closure_invoke
#40 signal_emit_unlocked_R
#41 g_signal_emit_valist
#42 g_signal_emit
#43 gtk_widget_event_internal
#44 gtk_propagate_event
#45 gtk_main_do_event
#46 gdk_event_dispatch
#47 g_main_context_dispatch
#48 g_main_context_iterate
#49 g_main_loop_run
#50 gtk_main
#51 main
at main-application.c line 500



Other information:
This executable was built on Mac OS X 10.4.6 using Mac's X11.  Libgsf and libgoffice were built the same way; the rest of the dependencies came from Fink.  Gnumeric 1.6.3 built the same way does not exhibit this bug.

Comment 1 Damien Durand 2006-07-18 13:44:33 UTC

Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug.

Comment 2 Morten Welinder 2006-07-18 15:47:52 UTC

Bug report is fine.  And I can reproduce.

We throw a critical in this case.  There are no null-pointers involved.

Comment 3 Morten Welinder 2006-07-18 16:36:16 UTC

2006-07-18  Morten Welinder  <terra@gnome.org>

	* src/application.c (gnm_app_workbook_get_by_name): Handle empty
	name.  Fixes #347916.

Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.

Comment 4 Morten Welinder 2006-07-18 16:40:14 UTC

2006-07-18  Morten Welinder  <terra@gnome.org>

	* src/application.c (gnm_app_workbook_get_by_name): Handle empty
	name.  Fixes #347916.

Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.

Comment 5 Morten Welinder 2006-07-21 19:42:57 UTC

Actually, in the non-gnome version there really was a null pointer
dereference.  While it can no longer be reached this way, I still
felt it right to fix go_url_resolve_relative (in goffice) by adding
preconditions that will catch this.