GNOME Bugzilla – Bug 334399
assertion crash in gtk_source_view_init()
Last modified: 2011-02-04 16:10:27 UTC
Steps to reproduce: 1. Compile glib with --disable-debug 2. Build gtksourceview 1.6.0 3. Build gedit Stack trace: laptop ~% gdb gedit GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/bin/gedit (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 30786)] GtkSourceView-CRITICAL **: gtk_source_view_init: assertion `tl != NULL' failed aborting... Program received signal SIGABRT, Aborted.
+ Trace 66890
Thread 16384 (LWP 30786)
Other information:
Note in the function gtk_source_view_init() the line g_return_if_fail (tl != NULL); just calls g_return_if_fail_warning(), which calls g_log() which calls g_logv() whose default action is to call abort() ! So this the staement above is not having the intended effect i guess...
well, an assertion it's an assertion: it's meant to be a sanity check that should never fails. What we need to figure out is *why* tl is NULL. Are you using gtk+ HEAD from cvs (2.9)?
Ok, looks like the breakage is due to the addition of rich text d'n'd to gtk: <pbor> mitch: can your rtf dnd work have affected gtk_drag_dest_get_target_list (GTK_WIDGET (view)) ? <pbor> (in the sense that it returns a null target list) <mitch> pbor: definitely <mitch> a NULL list? <pbor> it broke gtksourceview :( <mitch> it should definitely not do that, but get the target list from the buffer <pbor> mitch: http://bugzilla.gnome.org/show_bug.cgi?id=334399 <pbor> mitch: behdad sees that too with gtk HEAD <mclasen> pbor: whats the point of that return_if_fail ?! <pbor> (ironic that the bug reporter is called mitch despite not being you :) <pbor> mclasen: well, it's asserting that the target list is not null (I know using g_return_if_fail for that is not a good idea... not my code) <mclasen> but...why ? <pbor> mclasen: iirc gtksourceview adds support for dropping colors * pbor looks at the code <mclasen> yes, but why is it important that there are other targets supported by the text view before that ? <mclasen> oh, now I see. You need t1 to be non-NULL to add to it... <mclasen> well, if its null, you could just create a list yourself <pbor> yeah <mitch> hm that will fail badly <mclasen> but it _is_ suspicious that it is null in the first place <pbor> exactly <mitch> since as soon as you set the buffer, the view uses the buffer's target list <mitch> argh <mitch> gah that's evil <mclasen> mitch: clashes between toolkit-provided and app-provided targets are a recurring theme these days <mclasen> cf notebook... <mitch> that means richtext dnd breaks all users of GtkTextView which add their own drop targets <mclasen> mitch: you probably need to be careful to preserve preexisting targets, or something <mitch> mclasen: what about the "info" values in the list? <mclasen> you mean if they clash ? <mitch> yep <mclasen> bad luck <mitch> as in the standard enum { 0, 1, 2, ... } :( <mitch> they will almost always clash <mclasen> honestly, no idea <mclasen> maybe reserve negative numbers for toolkit use... <mitch> they are uint :/ <mitch> wait, are they?... <mitch> they are <mclasen> well, start counting down from MAXUINT then... <mitch> yea <mitch> in gtktextbuffer.h :( <mclasen> right <mitch> i will get something not entirely ugly hacked next week, after lgm
moving to gtk+
Created attachment 61685 [details] [review] Does this patch fix the problem? Attached patch makes sure that the text view always has its own target list. The text buffer's list is only used as source to copy targets into the view's list.
Well it seems some change in recent CVS of gtk+ make gedit no longer crash even *without* your patch Michael. I now only get the CRITICAL warning, but no subsequent crash.
that was because gnome 2.14 was released: during developement versions (2.13) warnings intentionally cause assertions so that they do not go unnoticed.
So shall i still apply patch and report ?
yes, that would be great
Ok, so i've recompiled gtk+ with the patch above and there is no more warning and no more crash. It looks fine to me, but i'm sure needs a few more days testing..
Confirmed that the patch fixes it here.
Does "fixes it" mean it doesn't warn/crash any more, or it doesn't warn/crash *and* the additional drop tragets work?
In other words (since the feature is pretty obscure) Mitch, Behdad can you to do the following: - open the Edit->Preferences dialog and go to the Fonts&Colors tab - enable custom colors - press one of the colors buttons - From the Color chooser dialog drag the from the rectangle below the color below the wheel and drop it on the textview It should insert #RRGGBB
Yes, DnDing the color works, and no warning.
Thanks. Comitted the patch as-is: 2006-03-22 Michael Natterer <mitch@imendio.com> * gtk/gtktextbuffer.h (enum GtkTextBufferTargetInfo): count down from G_MAXUINT to avoid clashes with application-added DND targets. * gtk/gtktextview.c (gtk_text_view_init): set an empty GtkTargetList on the drag_dest so it is not NULL when a derived class' init() function is called. (gtk_text_view_target_list_notify): copy the text buffer's paste targets into the view's destinstion target list (preserving application-added DND targets), instead of replacing the view's target list. Fixes bug #334399.