hypnotoad processes have corrupted /proc/<pid>/environ on certain OS

[andrii-suse]

• Mojolicious version: 9.32
• Perl version: 5.40
• Operating system: tumbleweed, debian, ubuntu (but not leap)

Steps to reproduce the behavior

Start app with hypnotoad script in Tumbleweed or debian or ubuntu

Expected behavior

Content of /proc/\<pid\>/environ should contain environment variables. Or at least document current behavior.

Actual behavior

Content of /proc/\<pid\>/environ looks corrupted: contains spaces, null bytes and sometimes meaningless characters.

In production environment on Tumbleweed content of /proc/\<pid\>/environ looks corrupted for processes created by hypnotoad script.

I reproduced problem with this test https://github.com/andrii-suse/mojo/blob/test_hypnotoad_environ/t/mojo/hypnotoad-environ.t

You can try these dockerfiles to reproduce the problem with the test above in various containers:
https://github.com/andrii-suse/mojo/tree/test_hypnotoad_environ/t/hypnotoad

The command like: podman build -f Dockerfile.tumbleweed .

Test logs for github actions https://github.com/andrii-suse/mojo/actions/runs/12391807120 confirm my observations: for latest Tumbleweed, Debian and Ubuntu output of hexdump -C /proc/$$/environ is like below:

00000000  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
00000180  00                                                |.|
00000181

For Leap it is expected behavior and output starts like

00000000  54 45 53 54 5f 48 59 50  4e 4f 54 4f 41 44 3d 31  |TEST_HYPNOTOAD=1|
00000010  00 48 4f 53 54 4e 41 4d  45 3d 61 36 64 38 61 62  |.HOSTNAME=a6d8ab|
00000020  31 36 35 64 65 34 00 50  57 44 3d 2f 6f 70 74 2f  |165de4.***
00000030  6d 6f 6a 6f 00 48 4f 4d  45 3d 2f 72 6f 6f 74 00  |mojo.HOME=/root.|

[andrii-suse]

I did experiment a bit more and can with confidence conclude that the corruption happens after this line

mojo/lib/Mojo/Server/Hypnotoad.pm

Line 41 in 2376b90

$0 = $ENV{HYPNOTOAD_APP} ||= path($app)->to_abs->to_string;

I guess it is unsafe to assign value to $0 in certain environments?

[kraih]

Very strange. Wonder if it has something to do with the filesystem and file name encoding. 🤔

[andrii-suse]

So the problem is much simpler that I thought initially and not sure if there is anything to do about it. Was able to reproduce with these commands on tumbleweed:

my $res = `hexdump -C /proc/$$/environ | head`;
print "res=$res $$\n";
$0='myapp.pl';
$res = `hexdump -C /proc/$$/environ | head`;
print "res=$res $$\n";

The first print command produces expected output, while the second (after assigning value to $0) has corrupted output.
So my main concerns was about environment variables in the child processes and all my testing confirmed that they are not affected, so it is mostly a concern for more complicated monitoring/debugging, etc.