Strange segfault

[Joshix-1]

I'm experiencing a reliable segfault on a VPS of mine, while running uwufetch from a python program. I can't reproduce this on my main machine or outside of the python program. I don't have any idea what the cause could be.

Output of dmesg:

[2296997.676920] uwufetch[602704]: segfault at 0 ip 00007fc7f4fe1f4a sp 00007ffee11ee228 error 4 in libc-2.33.so[7fc7f4ebb000+14b000]
[2296997.677083] audit: type=1701 audit(1632051413.051:55175): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=602704 comm="uwufetch" exe="/usr/bin/uwufetch" sig=11 res=1

output of journalctl:

Sep 19 13:36:53 vbox systemd-coredump[602706]: [🡕] Process 602704 (uwufetch) of user 1000 dumped core.

                                               Found module linux-vdso.so.1 with build-id: 68f6e36e0fd83223b553b19c82de3c4a799f606e
                                               Found module ld-linux-x86-64.so.2 with build-id: 040cc3dd10461562f177df39e3be2f3704258c3c
                                               Found module libc.so.6 with build-id: 4b406737057708c0e4c642345a703c47a61c73dc
                                               Found module uwufetch with build-id: e2e7629457d789d8a3f0d9784eff69b8075866d1
                                               Stack trace of thread 602704:
                                               #0  0x00007fc7f4fe1f4a __strcpy_ssse3 (libc.so.6 + 0x14cf4a)
                                               #1  0x0000556192861174 n/a (uwufetch + 0x2174)
                                               #2  0x0000556192860256 n/a (uwufetch + 0x1256)
                                               #3  0x00007fc7f4ebcb25 __libc_start_main (libc.so.6 + 0x27b25)
                                               #4  0x000055619286042e n/a (uwufetch + 0x142e)

uwufetch running fine on the same vps:

[ad-oliviero]

I tried some ways to run uwufetch with python:

#!/bin/env python3
import os
import subprocess

os.system("uwufetch")
print(os.popen("uwufetch").read())
subprocess.call("uwufetch")
subprocess.run("uwufetch")

But all of them work without problems, could you post the line where uwufetch is called? Do you edit some system variables in the program before running uwufetch?

[Joshix-1]

I run it with asyncio.create_subprocess_exec. (it didn't work with asyncio.create_subprocess_shell or os.popen either) It's really strange. I run the same code on two different machines and on one it works and on another (a vps) it doesn't.

How could editing system variables affect uwufetch? Or what could affect uwufetch in this way?

If you really want to see the code: https://github.com/asozialesnetzwerk/an-website/blob/main/an_website/host_info/host_info.py#L64 calls https://github.com/asozialesnetzwerk/an-website/blob/main/an_website/utils/utils.py#L165

[ad-oliviero]

I run it with asyncio.create_subprocess_exec.

I did the same and it works

It didn't work with asyncio.create_subprocess_shell or os.popen either

With os.popen you should call its read() method

It's really strange. I run the same code on two different machines and on one it works and on another (a vps) it doesn't.

What if you use gdb to debug it in the python script (if you have access to the console)?

How could editing system variables affect uwufetch? Or what could affect uwufetch in this way?

In some cases changing some variable (i. e. $LANG) some program called by uwufetch could change its output and break the get_info() function

[ad-oliviero]

Sorry, miss clicked

[Joshix-1]

I think the ekzem is that the python program gets run with supervisord. That means that not all the required env vars are set. LANG, PATH, HOME, USER are all set

Some observations:

• running env -i uwufetch produces a segfault.

• uwufetch uses vfork often

• dumping the current env in a text and then using it to run uwufetch produces an error the command: env | sed -E 's/^([^=]+)=(.+)$/\1="\2"/g' > env.txt

[ad-oliviero]

Yes this is the solution, $HOME and $SHELL are not set in env