Thunar terminal open segfault about fastfetch HOT 13 CLOSED

I tried to reproduce, but exo-open fails to find TerminalEmulator when installing only it. As i don't want to pull in the whole XFCE ecosystem, i leave this one for you. Most probably something in /src/common/detectTerminalShell.c or src/common/packages.c. Run with --multithreading false to see if it is the shell or the package code that crashes.

from fastfetch.

Turning off multithreading just makes it crash later in the process

It makes it past the package module just fine.

It seems to be Thunar related (not exo-open), as setting the command line to just be "alacritty" will produce the same crash.

edit: Also happens with tilix and xfce4-terminal. Neofetch works fine.

from fastfetch.

Seems like an error in src/common/detectWMDE.c. Can you check that? Probably an error in XFCE specific code.

from fastfetch.

Possible that sessionDesktop is somehow NULL? applyPrettyNameIfWM doesn't check for that even that case is possible, see this line (365):

//If sessionDesktop is a known WM, set it.
applyPrettyNameIfWM(result, result->sessionDesktop, &protocolHint);

the check must be added anyway at top of the function, similar to applyPrettyNameIfDE:

if(name == NULL || *name == '\0')
    return;

If you open a PR, and this is not the error, you can include that fix too.

from fastfetch.

So there's definitely something weird going on with with terminal detection when launched from Thunar.
Plasma/KWin:

LXQt/Openbox:

The only one that actually segfaults is regular Openbox.

from fastfetch.

I added

if(processName == NULL || *processName == '\0')
        return;

to the start of applyPrettyNameIfWM.

That's what you meant, right?

Edit: The segfault is gone - the garbage output is still there as with the others though.

from fastfetch.

Here's the process that's launched:

from fastfetch.

The terminal font module seems to know the terminal name at least:

from fastfetch.

Turning off multithreading removes the random garbage on each run and leaves the line blank. I'm not sure where to go from here.

Is it safe to call getTerminalShell() recursively?

from fastfetch.

Should be. However im still unable to reproduce, even in a VM with similar setup. This makes it hard to find the cause. Maybe use gdb too see where things go wrong?

from fastfetch.

In terminal.c,

if(instance->config.terminalFormat.length == 0)
    {
        ffPrintLogoAndKey(instance, FF_TERMINAL_MODULE_NAME, 0, &instance->config.terminalKey);
      //  puts(result->terminalExeName);
      printf("\nresult->terminalProcessName: %s\nresult->terminalExe: %s\nresult->terminalExeName: %s\n", result->terminalProcessName.chars, result->terminalExe.chars, result->terminalExeName);
    }

So result->terminalExeName is not valid for some reason.

Here's the terminal launched normally:

from fastfetch.

Is it possible that your terminalExe ends with a slash at any point? This would fail then:

uint32_t lastSlashIndex = ffStrbufLastIndexC(exe, '/');
if(lastSlashIndex < exe->length)
    *exeName = exe->chars + lastSlashIndex + 1;

from fastfetch.

Inactive.

from fastfetch.