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 648381 - Crashes with long words in strings passed to gtk_widget_set_tooltip_text()
Crashes with long words in strings passed to gtk_widget_set_tooltip_text()
Status: RESOLVED DUPLICATE of bug 698758
Product: gtk+
Classification: Platform
Component: Backend: X11
2.22.x
Other FreeBSD
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2011-04-21 14:58 UTC by Fabian Keil
Modified: 2013-07-24 10:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example program (by Colin Leroy) that shows the problem (9.94 KB, text/x-csrc)
2011-04-21 14:58 UTC, Fabian Keil
  Details
Patch that prevents the crashes for me (1.65 KB, patch)
2011-04-21 15:02 UTC, Fabian Keil
reviewed Details | Review

Description Fabian Keil 2011-04-21 14:58:29 UTC
Created attachment 186430 [details]
Example program (by Colin Leroy) that shows the problem

The attached example program (by Colin Leroy) passes a string
with a long "word" to gtk_widget_set_tooltip_text() which causes
a crash when the tooltip is supposed to be shown.

(gdb) r --sync
Starting program: /home/fk/kram/tooltip-crashes/long_tooltip_crash --sync
[New LWP 101212]
[New Thread 805407400 (LWP 101212/initial thread)]

(long_tooltip_crash:65109): Gdk-WARNING **: Native Windows wider or taller than 65535 pixels are not supported

Gdk-ERROR **: The program 'long_tooltip_crash' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 725 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...

Program received signal SIGABRT, Aborted.

Thread 805407400 (LWP 101212/initial thread)

  • #0 thr_kill
    from /lib/libc.so.7
  • #1 abort
    from /lib/libc.so.7
  • #2 g_logv
    at gmessages.c line 557
  • #3 g_log
    at gmessages.c line 577
  • #4 gdk_x_error
    at gdkmain-x11.c line 466
  • #5 _XError
    at XlibInt.c line 3105
  • #6 handle_error
    at xcb_io.c line 166
  • #7 handle_response
    at xcb_io.c line 265
  • #8 _XReply
    at xcb_io.c line 554
  • #9 XSync
    at Sync.c line 46
  • #10 _XSyncFunction
    at Synchro.c line 35
  • #11 _XPrivSyncFunction
    at XlibInt.c line 603
  • #12 XCreatePixmap
    at CrPixmap.c line 58
  • #13 _gdk_pixmap_new
    at gdkpixmap-x11.c line 175
  • #14 IA__gdk_pixmap_new
    at gdkpixmap.c line 249
  • #15 gdk_window_begin_implicit_paint
    at gdkwindow.c line 2773
  • #16 gdk_window_process_updates_internal
    at gdkwindow.c line 5569
  • #17 IA__gdk_window_process_updates
    at gdkwindow.c line 5757
  • #18 gtk_window_move_resize
    at gtkwindow.c line 6246
  • #19 gtk_window_check_resize
    at gtkwindow.c line 5408
  • #20 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 79
  • #21 g_type_class_meta_marshal
    at gclosure.c line 877
  • #22 g_closure_invoke
    at gclosure.c line 766
  • #23 signal_emit_unlocked_R
    at gsignal.c line 3290
  • #24 g_signal_emit_valist
    at gsignal.c line 2983
  • #25 g_signal_emit
    at gsignal.c line 3040
  • #26 IA__gtk_container_check_resize
    at gtkcontainer.c line 1431
  • #27 gtk_container_idle_sizer
    at gtkcontainer.c line 1356
  • #28 gdk_threads_dispatch
    at gdk.c line 512
  • #29 g_idle_dispatch
    at gmain.c line 4254
  • #30 g_main_dispatch
    at gmain.c line 2149
  • #31 g_main_context_dispatch
    at gmain.c line 2702
  • #32 g_main_context_iterate
    at gmain.c line 2780
  • #33 g_main_loop_run
    at gmain.c line 2988
  • #34 IA__gtk_main
    at gtkmain.c line 1237
  • #35 main

I'm using GTK+ 2.22.1.

From the documentation at:
http://developer.gimp.org/api/2.0/gtk/GtkWidget.html#gtk-widget-set-tooltip-text
the expected behaviour isn't clear.

According to the gtk-devel-list@ thread crashing is considered a bug,
though, and I happen to agree:
http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00119.html

Morten Welinder noted in the same thread that Gnumeric had been
affected by this problem in the past.

Emmanuel Thomas-Maurin pointed out that the GDK warning is already a
sign that the tooltip width has been truncated.

The crash seems to indicate that the limit is too high, though.
Limiting the width (and height) to 16384 prevents the crashes for me.
I previously tried both 32767 and 32767-1 but still got the crashes.

I didn't try anything between 16384 and 32767-1 so the
actual limit may be higher (and not connected to 2**n).

Note that at least in my case the height isn't a problem and
I don't know if height and width really do have the same upper
limit.

If the tooltip text comes from an untrusted source the source can
crash the application so this is at least somewhat security-related.
From the documentation it isn't clear that (and how) strings passed
to gtk_widget_set_tooltip_text() would have to be validated first.
Comment 1 Fabian Keil 2011-04-21 15:02:02 UTC
Created attachment 186431 [details] [review]
Patch that prevents the crashes for me

This is the patch that prevents the crashes for me.

As noted in the main comment, the chosen limit happens
to work for me but the actual limit may be higher.
Comment 2 Mikael Magnusson 2011-04-21 17:26:25 UTC
Wouldn't it make a lot more sense if tooltips were limited and force-wrapped at the screen width, so you can actually _read_ the text in them?
Comment 3 Fabian Keil 2011-04-21 19:09:11 UTC
I agree that this would be even better, but for it to
really make "a lot more sense" you would also have to
make sure that long tooltips start at the left side
of the screen.

Currently this doesn't seem to be the case, so just
force-wrapping the tooltip to the screen width isn't
sufficient to make the whole text readable.

Having said that, I think if the tooltip text is wide
enough to cause the crash it's rather unlikely that the
user is going to completely read it anyway.

Therefore I'm not sure optimizing the behaviour in that
situation (except for not crashing) is really worth it.

An improvement that I think might be worth it, would be
to make sure that the beginning of the tooltip is always
visible and only the end of the text is truncated.

Of course the location of the beginning of the text depends
on the language so that, too, sounds like a lot of work for
little benefit to me.
Comment 4 Morten Welinder 2013-06-20 14:27:57 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 698758 ***
Comment 5 Emmanuele Bassi (:ebassi) 2013-07-24 10:25:48 UTC
Review of attachment 186431 [details] [review]:

::: gdk/x11/gdkwindow-x11.c
@@ -666,2 +666,3 @@
   const char *title;
   int i;
+  static const height_and_width_limit = 16384;

this could very well be a #define instead of a static variable, e.g.:

  #define MAX_WINDOW_SIZE (G_MAXUINT16 / 2)

it would be nicer if we had an actual value we could get from Xlib, to avoid encoding magic values inside GDK, though.

@@ +786,1 @@
+      if (private->width > height_and_width_limit)

this could be replaced by a simpler:

  private->width = MIN (private->width, MAX_WINDOW_SIZE);
  private->height = MIN (private->height, MAX_WINDOW_SIZE);