(Aside note: GIMP seems to be receiving a preferential treatment from GTK devs.
On http://gtk.org/bugs.html, they say: "Bugs that can be reproduced within the
GIMP are almost as good as bugs that can be reproduced in testgtk." Given
Inkscape's importance to the community - it's one of the most popular GTK apps
- I think Inkscape deserves no less. As for this particular bug, I have examined it closely and I'm convinced that it's a bug in GTK, not in Inkscape code, but it would be quite difficult for me to provide a test app. So I'm hoping you will be able to reproduce it by running Inkscape SVN, as explained in detail below.)

In SVN version, Inkscape implemented interruptible display. This means that, while redrawing screen, Inkscape stops from time to time and runs several Gtk::Main::iteration() if there are  Gtk::Main::events_pending(). This helped to improve the editing experience tremendously, making Inkscape much more responsive: for example you can now zoom in or out without waiting for the current screen to fully redraw. However, this also revealed problems with GTK.

In the Fill and Stroke dialog, we have Blur controls: a slider and a spinbutton, both connected to the same GtkAdjustment. These controls change the blur of the selected object. Rendering blurred objects is quite slow, so if you set a large blur, Inkscape will run main loop iterations while redrawing its canvas. The sequence of events is like this:

- The user clicks in the Blur spinbutton, giving it focus. 

- The user then drags the Blur slider.

- This fires the adjustment's value-change callback.

- The callback changes the document and causes canvas redraw.

- While redrawing canvas (so, still within the value-changed callback), Inkscape runs Gtk::Main::iteration() to process pending events.

- One of the events-to-process seems to be the "blink spinbutton cursor" event that GTK generates and tries to process. However, the spinbutton no longer has focus - it was moved to the slider when it was dragged! So GTK crashes with:

(inkscape:5018): Gtk-WARNING **: GtkEntry - did not receive focus-out-event. If
you connect a handler to this signal, it must return FALSE so the entry gets the event as well

Gtk-ERROR **: file gtkentry.c: line 5260 (blink_cb): assertion failed:
(GTK_WIDGET_HAS_FOCUS (entry))
aborting...

This bug was reported by an Inkscape user:

http://sourceforge.net/tracker/index.php?func=detail&aid=1580903&group_id=93438&atid=604306

Obviously, something is very wrong here. GTK seems to get out of sync with itself and tries to blink a defocused spinbutton. 

This is only one of the troubles; another is that typing a value into the Blur spinbutton (e.g. 20) and pressing Enter seems to produce multiple value-changed events: while redrawing screen after the change, a main loop iteration brings ANOTHER value-changed which ups blur to 40, then to 80, etc until it reaches the maximum and then stops. 

The root problem seems to be that GTK is unable to cope with the situation where a value-changed callback runs a main loop iteration _from itself_. Please review your code with an eye to this. Issuing of events must not depend on whether the last value-changed callback has finished or is still running!

For now, I fixed this crash in Inkscape by disabling interruptible display while the blur adjustment callback updates the document and redraws. Of course it's not a real fix, just a workaround which damages responsiveness of the program. Please do a proper fix in GTK, or explain me what I am doing wrong if anything. 

To experience this bug, build Inkscape SVN with this change reverted:

http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/dialogs/object-properties.cpp?r1=13242&r2=13257&sortby=date

Please contact me with any questions, or if you need any help on building/running Inkscape.

Additional info: I tried using gtk_main_iteration_do instead of Gtk::Main::Iteration but that didn't fix it. Also, passing true or false to Gtk::Main::Iteration does not affect the bug.