Crash on invalid OSC 7 URL

[egmontkob]

This causes a segfault:

printf '\e]7;file://525198bb6eda/bin\e\\'; sleep 1000

Probably the same story as gnome-terminator/terminator#966 and https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/345, although in Tilix you don't even need to split the layout, the crash (segfault) occurs immediately after encountering an OSC 7 sequence with an invalid hostname.

I presume the reason is the same, an uncaught exception in URI.filenameFromUri(), or somewhere nearby.

[algj]

Yup, can replicate this, and seems like it is a VTE issue (tilix, xfce4 and terminator are using VTE)

I was unable to find the issue on VTE repo, you may want to report it here: https://gitlab.gnome.org/GNOME/vte/-/issues

Thanks!

---

To make sure it's not a bug on tilix, I checked the gdb's backtrace, and SIGSEGV indeed happens in libvte...:

#0  emission_find (signal_id=1, detail=1892, instance=0x55555666de40) at ../glib/gobject/gsignal.c:793
#1  signal_emit_unlocked_R.isra.0
    (node=node@entry=0x7fffffffd6b0, detail=detail@entry=1892, instance=instance@entry=0x55555666de40, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd5a0) at ../glib/gobject/gsignal.c:3683
#2  0x00007ffff716bca9 in signal_emit_valist_unlocked
    (instance=instance@entry=0x55555666de40, signal_id=signal_id@entry=1, detail=detail@entry=1892, var_args=var_args@entry=0x7fffffffd820)
    at ../glib/gobject/gsignal.c:3519
#3  0x00007ffff716bf32 in g_signal_emit_valist (instance=0x55555666de40, signal_id=1, detail=1892, var_args=var_args@entry=0x7fffffffd820)
    at ../glib/gobject/gsignal.c:3262
#4  0x00007ffff716bff4 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>)
    at ../glib/gobject/gsignal.c:3582
#5  0x00007ffff7156d16 in g_object_dispatch_properties_changed (object=0x55555666de40, n_pspecs=<optimized out>, pspecs=<optimized out>)
    at ../glib/gobject/gobject.c:1819
#6  0x00007ffff714b118 in g_object_notify_queue_thaw (object=0x55555666de40, nqueue=<optimized out>, take_ref=1) at ../glib/gobject/gobject.c:755
#7  0x00007ffff59e3857 in ??? () at /usr/lib/libvte-2.91.so.0
#8  0x00007ffff5a1dcc9 in ??? () at /usr/lib/libvte-2.91.so.0
#9  0x00007ffff5a1e097 in ??? () at /usr/lib/libvte-2.91.so.0
#10 0x00007ffff5a1e193 in ??? () at /usr/lib/libvte-2.91.so.0
#11 0x00007ffff5a1e2ed in ??? () at /usr/lib/libvte-2.91.so.0
#12 0x00007ffff5a0393b in ??? () at /usr/lib/libvte-2.91.so.0
#13 0x00007ffff6544f6d in gtk_widget_on_frame_clock_update (frame_clock=0x5555569e3fa0, widget=0x55555666de40) at ../gtk/gtk/gtkwidget.c:5287
#17 0x00007ffff716bff4 in <emit signal 'update' on instance ???>
    (instance=instance@entry=0x5555569e3fa0, signal_id=<optimized out>, detail=detail@entry=0) at ../glib/gobject/gsignal.c:3582
    #14 0x00007ffff716be1c in _g_closure_invoke_va
    (closure=0x555556ab44b0, return_value=0x0, instance=0x5555569e3fa0, args=0x7fffffffde50, n_params=0, param_types=0x0)
    at ../glib/gobject/gclosure.c:896
    #15 signal_emit_valist_unlocked
    (instance=instance@entry=0x5555569e3fa0, signal_id=signal_id@entry=30, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffde50)
    at ../glib/gobject/gsignal.c:3423
    #16 0x00007ffff716bf32 in g_signal_emit_valist (instance=0x5555569e3fa0, signal_id=30, detail=0, var_args=var_args@entry=0x7fffffffde50)
    at ../glib/gobject/gsignal.c:3262
#18 0x00007ffff721306e in _gdk_frame_clock_emit_update (frame_clock=0x5555569e3fa0) at ../gtk/gdk/gdkframeclock.c:645
#19 gdk_frame_clock_paint_idle (data=0x5555569e3fa0) at ../gtk/gdk/gdkframeclockidle.c:547
#20 0x00007ffff71feac0 in gdk_threads_dispatch (data=0x555556a358f0) at ../gtk/gdk/gdk.c:769
#21 0x00007ffff740da0a in g_timeout_dispatch (source=0x55555675f7a0, callback=<optimized out>, user_data=<optimized out>)
    at ../glib/glib/gmain.c:5070
#22 0x00007ffff740c559 in g_main_dispatch (context=0x5555564c92f0) at ../glib/glib/gmain.c:3357
#23 0x00007ffff746f157 in g_main_context_dispatch_unlocked (context=0x5555564c92f0) at ../glib/glib/gmain.c:4208
#24 g_main_context_iterate_unlocked.isra.0
    (context=context@entry=0x5555564c92f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4273
#25 0x00007ffff740ba55 in g_main_context_iteration (context=context@entry=0x5555564c92f0, may_block=may_block@entry=1)
    at ../glib/glib/gmain.c:4338
#26 0x00007ffff6ea9cb6 in g_application_run (application=0x5555565b01c0, argc=<optimized out>, argv=0x7ffff7a4d3c0)
    at ../glib/gio/gapplication.c:2715
#27 0x0000555555eb8ab6 in gio.Application.Application.run(immutable(char)[][]) (this=0x7ffff7a13200, argv=...)
    at ../../.dub/packages/gtk-d/3.10.0/gtk-d/generated/gtkd/gio/Application.d:931
#28 0x0000555555ce813d in D main (args=...) at source/app.d:162

[egmontkob]

This is weird.

In Terminator, the crash on the same kinds of URLs occurs within Terminator itself, as it's clear by the stack trace over there.

VTE does absolutely no parsing or any other kind of work on the value of OSC 7. It's a just string. It notifies you when it changes (apparently this is what happens here) or lets you query it. That's all. If there was a related crash in VTE, it would crash on valid and invalid URLs equally.

Trust me, I'm a VTE developer. Also note that quite a few other VTE-based apps which do use the value set by OSC 7, e.g. GNOME Terminal, work fine and do not crash.

I'm not familiar with the D programming language and its surrounding infrastructure, but my best guess (without having thorougly investigated) is that for whatever reason the crashing method running in D doesn't show up in the stack trace. Although, the underlying GLib method that I believe actually crashes also doesn't show up while other GLib methods do. Really weird. Definitely needs further investigation.

[egmontkob]

the underlying GLib method that I believe actually crashes

Stupid me here. The underlying GLib method doesn't crash. It returns a value that I believe should cause the D binding to generate an exception. That is, this GLib method should no longer be on the stack, this part is fine.

And, in turn, maybe any other methods that don't catch the exception are also removed from the stack as the exception is getting propagated?

[egmontkob]

There are 3 occurrences of URI.filenameFromUri() in Tilix's source, 1 of which is inside a throw-catch, i.e. expecting that the method might throw, but the other 2 aren't.

[egmontkob]

FYI: GLib should accept hostnames beginning with a digit, this is tracked in https://gitlab.gnome.org/GNOME/glib/-/issues/3523. Looks like there's a good chance they'll fix it soon and then Tilix won't crash on such hostnames.

Also, #2245 has just been reported, same kind of crash if a hostname (as given to Tilix in an OSC 7 sequence) contains an underscore character. That one is clearly invalid as hostname, so GLib surely won't be changed to accept that. Tilix definitely needs to tolerate faulty hostnames in an OSC 7.