Tilix crashes (segfaults) when activating conda environment

[hmcezar]

After the last Manjaro GNOME update (which updated to GNOME 47.1) Tilix is crashing whenever I try to activate a conda environment.

These are the versions:

Versions
	Tilix version: 1.9.6
	VTE version: 0.78
	GTK Version: 3.24.43

Tilix Special Features
	Notifications enabled=0
	Triggers enabled=0
	Badges enabled=1

And this is what is logged:

[ 1845.461248] tilix[18031]: segfault at 9 ip 00007fac33ea0d98 sp 00007ffc6b63daa0 error 4 in libgobject-2.0.so.0.8200.2[7fac33e6b000+38000] likely on CPU 4 (core 0, socket 0)

Apart from the conda environment, everything else seems to work fine. GNOME Terminal also works fine.

[egmontkob]

Could you please run within Tilix the command script -f, and in this session the Conda initialization steps (preferably as few as possible to reproduce the crash)?

This will create a file called typescript, logging all the data sent from Conda to Tilix. Replaying and debugging that data can hopefully locate the problem. Please make sure that no sensible or secret data is printed, and then attach that file.

[hmcezar]

Hi, thanks for the comment.

I've done as you suggested and the log has many weird characters (I don't know the encoding it's using).
I the extension .txt to attach it:
typescript.txt

[egmontkob]

Thanks! I can reproduce the problem by slowly replaying that file (using the slowcat utility found in VTE's source).

The trigger within the file is the OSC 7 escape sequence with file://x86_64-conda-linux-gnu/home/hmcezar as its parameter (denoting the hostname and current working directory). More particularly, the underscore (_) character within the hostname.

A simpler reproducer is:

 printf '\e]7;file://foo_bar/usr/bin\e\\'; sleep 1

(The sleep is there because otherwise your shell prompt may emit another OSC 7 overwriting this one in quick succession, and then VTE may skip that intermittent value and not notify Tilix about that. In other words, it's there to give time for things to settle.)

It's a duplicate of the just recently discovered #2244. In addition to the hostname beginning with a digit, apparently a hostname containing an underscore isn't supported either by GLib's corresponding method (which is arguably a bug in GLib, but that's not the point here), and Tilix forgets to handle the exception or the error condition.

[egmontkob]

Apparently underscore isn't a valid character in DNS resolution, and my kernel (on Ubuntu 24.10) also refuses to set such a hostname using the hostname utility. That being said, some claim that for local use not everyone forbids the underscore. E.g. technically nothing can stop the HOSTNAME env var from containing such a value.

And even if was universally a forbidden character, that wouldn't be a reason for Tilix to crash on an escape sequence containing such an invalid URL.

That being said, you can perhaps work around the issue by not using that (pseudo-)hostname of x86_64-conda-linux-gnu with a dash anywhere. If you have a means of controlling that hostname, that is.

The typescript has two OSC 7 sequences right after each other (separator spaces, and C-style escaping added by me for readability), both setting the same directory, but the first one with this hostname and the second one without any. Interestingly they use a different terminator for the OSC 7 sequence, the first one uses the unofficial and the second uses the official one:

\e]7;file://x86_64-conda-linux-gnu/home/hmcezar\a  \e]7;file:///home/hmcezar\e\\

I'm not entirely sure from the typescript who is printing these sequences, but I suspect it is your shell (zsh I guess, with some fancy prompt), and not conda itself. No idea where it takes that hostname from, and how conda changes that. Maybe as a workaround somewhere hereabouts you could configure them not to set this as the hostname, or not to print that OSC 7.

The real fix preventing the crash needs to happen in Tilix of course. I'm not a Tilix developer so unfortunately I can't help with that one. Until then maybe you can find some workaround along these above lines.

[xZero707]

Still not fixed as of today.

For me it happens when I drop into docker container shell that uses fish. Same on all systems I tried on.
Reproducer above reliably crashes it on every system.

EDIT: It's the container hostname that causes it to crash. This aligns with #2244