ValveSoftware / halflife

Half-Life 1 engine based games
Other
3.71k stars 626 forks source link

At start crashes with sysmalloc assertion #3158

Open SGmuwa opened 3 years ago

SGmuwa commented 3 years ago

I tried to run CS:CZ on my computer and it doesn't work. I opened a terminal to see stderr and stdout:

msidorenko@PC048:~/.steam/debian-installation/steamapps/common/Half-Life$ ./hl.sh
hl_linux: malloc.c:2516: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

I tried to run on someone else's computer, and the game is work.

property value my computer (bad) value friend's computer (good)
Operating System Kubuntu 21.10 Kubuntu 21.04
KDE Plasma Version 5.22.5 5.21.4
KDE Frameworks Version 5.86.0 5.80.0
Qt Version 5.15.2 5.15.2
Kernel Version 5.13.0-20-generic (64-bit) 5.11.0-36-generic
Graphics Platform X11 X11
Processors 8 × Intel® Core™ i5-8300H CPU @ 2.30GHz 3 × AMD Athlon(tm) II X3 450 Processor
Memory 15.4 GiB of RAM 3.8 GiB of RAM
Graphics Processor Mesa DRI Intel® UHD Graphics 630 NV98

I tried changing the kernel from 5.13.0-20-generic to version 5.11.0-36-generic, but the error persisted. The error occurs even if I try to start without a graphical shell (Ctrl + Alt + f3). How do I run the game on my system?

SGmuwa commented 3 years ago

2021-11-02 20:24:54 UTC+4 cs:sz.strace.bash.log 2021-11-02 20:33:28 cs:cz.strace.hl_linux.log

kellerman commented 2 years ago

Found out that launching Steam and the game using Lutris then works. Must set option to show mangohud with Vulkan. Then it wierdly works.

ry755 commented 2 years ago

I'm having the same issue with Half-Life on Fedora 35 (KDE spin).

aguadecoco1301 commented 1 year ago

I have the same issue in Linux Mint 21.1 with XFCE desktop in Conter-Strike and CS:Condition Zero

ghost commented 1 year ago

I've been investigating this issue a bit and my conclusion is that one (or potentially all) of the shared libraries (e.g. hw.so) gets loaded incorrectly (maybe it's because of some loading flag). In turn, when hw.so tries to do a inter-modular call to an external library (say libopenal.so or libSDL2-2.0.so) which needs to allocate a bigger chunk of memory, glibc throws with:

 __libc_assert_fail (
    assertion=0xf79bff4c "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", file=0xf79bb0c9 "malloc.c", line=2593, function=0xf79c072c <__PRETTY_FUNCTION__.8> "sysmalloc") at __libc_assert_fail.c:31

Here is the first stack trace I get, while hw.so gets loaded:

#0  0xf7fc7549 in __kernel_vsyscall ()
#1  0xf78880c7 in __pthread_kill_implementation (threadid=threadid@entry=4159254528, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:43
#2  0xf788814f in __pthread_kill_internal (signo=6, threadid=4159254528) at pthread_kill.c:78
#3  0xf7835be7 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#4  0xf781e126 in __GI_abort () at abort.c:79
#5  0xf781f040 in __libc_message (fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:150
#6  0xf782ddd7 in __libc_assert_fail (
    assertion=0xf79bff4c "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", file=0xf79bb0c9 "malloc.c", line=2593, function=0xf79c072c <__PRETTY_FUNCTION__.8> "sysmalloc") at __libc_assert_fail.c:31
#7  0xf7896394 in sysmalloc (nb=nb@entry=101392, av=av@entry=0xf7a20760 <main_arena>) at malloc.c:2593
#8  0xf7897096 in _int_malloc (av=av@entry=0xf7a20760 <main_arena>, bytes=bytes@entry=101376) at malloc.c:4393
#9  0xf7897d97 in __GI___libc_malloc (bytes=101376) at malloc.c:3297
#10 0xf7c86e4c in operator new (sz=101376) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/new_op.cc:50
#11 0xf5af6522 in std::make_unique<double [][33][24]> (__num=16) at /usr/include/c++/12.2.1/bits/unique_ptr.h:1080
#12 0xf5af55ae in (anonymous namespace)::BSincFilterArray<(anonymous namespace)::bsinc12_hdr>::BSincFilterArray (this=0xf5c11d60 <(anonymous namespace)::bsinc12_filter>)
    at /home/user/Projects/openal-soft/core/bsinc_tables.cpp:175
#13 0xf5af6479 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/user/Projects/openal-soft/core/bsinc_tables.cpp:272
#14 0xf5af64b3 in _GLOBAL__sub_I_bsinc_tables.cpp(void) () at /home/user/Projects/openal-soft/core/bsinc_tables.cpp:295
#15 0xf7fce21b in call_init (env=0x8052bb0, argv=0xffffd5c4, argc=1, l=<optimized out>) at dl-init.c:70
#16 call_init (l=<optimized out>, argc=1, argv=0xffffd5c4, env=0x8052bb0) at dl-init.c:26
#17 0xf7fce313 in _dl_init (main_map=<optimized out>, argc=1, argv=0xffffd5c4, env=0x8052bb0) at dl-init.c:117
#18 0xf7fd4fbb in call_dl_init (closure=0xffffc3f0) at dl-open.c:485
#19 0xf7fca5c7 in __GI__dl_catch_exception (exception=0x0, operate=0xf7fd4fa0 <call_dl_init>, args=0xffffc3f0) at dl-catch.c:211
#20 0xf7fd4f41 in dl_open_worker (a=0xffffc538) at dl-open.c:808
#21 0xf7fca52d in __GI__dl_catch_exception (exception=0xffffc52c, operate=0xf7fd4ea0 <dl_open_worker>, args=0xffffc538) at dl-catch.c:237
#22 0xf7fd52ec in _dl_open (file=0xffffcfa0 "/home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so", mode=-2147483646, caller_dlopen=0x8049555 <Sys_LoadModule(char const*)+181>, 
    nsid=-2, argc=1, argv=0xffffd5c4, env=0x8052bb0) at dl-open.c:884
#23 0xf788131c in dlopen_doit (a=0xffffc75c) at dlopen.c:56
#24 0xf7fca52d in __GI__dl_catch_exception (exception=0xffffc6c4, operate=0xf78812a0 <dlopen_doit>, args=0xffffc75c) at dl-catch.c:237
#25 0xf7fca659 in _dl_catch_error (objname=0xffffc714, errstring=0xffffc718, mallocedp=0xffffc713, operate=0xf78812a0 <dlopen_doit>, args=0xffffc75c) at dl-catch.c:256
#26 0xf7880d47 in _dlerror_run (operate=<optimized out>, args=<optimized out>) at dlerror.c:138
#27 0xf78813e8 in dlopen_implementation (dl_caller=<optimized out>, mode=2, file=0xffffcfa0 "/home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so") at dlopen.c:71
#28 ___dlopen (file=0xffffcfa0 "/home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so", mode=2) at dlopen.c:81
#29 0x08049555 in Sys_LoadModule (pModuleName=0x804a068 "hw.so") at ../public/interface.cpp:159
#30 0x08049017 in main (argc=1, argv=0xffffd5c4) at ../launcher/launcher.cpp:427

(I recompiled lib32-openal with debug symbols, so I could trace this)

Here's the offending function for reference: https://github.com/kcat/openal-soft/blob/master/core/bsinc_tables.cpp#L169

Then I commented out all instantiations of bsinc12_filter/bsinc24_filter (and also gBSinc12/gBSinc24) in lib32-openal source code and recompiled, and then I got another assertion, but this time in libSDL2-2.0.so.0:

#0  0xf7fc7549 in __kernel_vsyscall ()
#1  0xf78880c7 in __pthread_kill_implementation (threadid=threadid@entry=4159254528, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:43
#2  0xf788814f in __pthread_kill_internal (signo=6, threadid=4159254528) at pthread_kill.c:78
#3  0xf7835be7 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#4  0xf781e126 in __GI_abort () at abort.c:79
#5  0xf781f040 in __libc_message (fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:150
#6  0xf782ddd7 in __libc_assert_fail (
    assertion=0xf79bff4c "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", file=0xf79bb0c9 "malloc.c", line=2593, function=0xf79c072c <__PRETTY_FUNCTION__.8> "sysmalloc") at __libc_assert_fail.c:31
#7  0xf7896394 in sysmalloc (nb=nb@entry=16400, av=av@entry=0xf7a20760 <main_arena>) at malloc.c:2593
#8  0xf7897096 in _int_malloc (av=av@entry=0xf7a20760 <main_arena>, bytes=bytes@entry=16384) at malloc.c:4393
#9  0xf78989b6 in __libc_calloc (n=1, elem_size=16384) at malloc.c:3664
#10 0xf5737064 in XOpenDisplay (display=0x0) at /build/lib32-libx11/src/libX11-1.8.4/src/OpenDis.c:241
#11 0xf7b64cea in ?? () from /home/user/.local/share/Steam/steamapps/common/Half-Life/libSDL2-2.0.so.0
#12 0xf7b6e5b7 in ?? () from /home/user/.local/share/Steam/steamapps/common/Half-Life/libSDL2-2.0.so.0
#13 0xf7b5dd01 in SDL_VideoInit () from /home/user/.local/share/Steam/steamapps/common/Half-Life/libSDL2-2.0.so.0
#14 0xf7ad6843 in SDL_InitSubSystem () from /home/user/.local/share/Steam/steamapps/common/Half-Life/libSDL2-2.0.so.0
#15 0xf600ff51 in BaseUISurface::BaseUISurface (this=0xf675b5a0 <g_BaseUISurface>) at ../engine/vgui2/BaseUISurface.cpp:153
#16 0xf5ef4c2c in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ../engine/vgui2/BaseUISurface.cpp:78
#17 _GLOBAL__sub_I_g_BaseUISurface () at ../engine/vgui2/BaseUISurface.cpp:1573
#18 0xf606b7aa in __do_global_ctors_aux () from /home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so
#19 0xf5ef3c05 in _init () from /home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so
#20 0x00000001 in ?? ()
#21 0x00000001 in ?? ()
#22 0xf7fce1e1 in call_init (env=0x8052bb0, argv=0xffffd5c4, argc=-168870907, l=0x8054850) at dl-init.c:56
#23 call_init (l=0x8054850, argc=-168870907, argv=0xffffd5c4, env=0x8052bb0) at dl-init.c:26
#24 0xf7fce313 in _dl_init (main_map=<optimized out>, argc=1, argv=0xffffd5c4, env=0x8052bb0) at dl-init.c:117
#25 0xf7fd4fbb in call_dl_init (closure=0xffffc3f0) at dl-open.c:485
#26 0xf7fca5c7 in __GI__dl_catch_exception (exception=0x0, operate=0xf7fd4fa0 <call_dl_init>, args=0xffffc3f0) at dl-catch.c:211
#27 0xf7fd4f41 in dl_open_worker (a=0xffffc538) at dl-open.c:808
#28 0xf7fca52d in __GI__dl_catch_exception (exception=0xffffc52c, operate=0xf7fd4ea0 <dl_open_worker>, args=0xffffc538) at dl-catch.c:237
#29 0xf7fd52ec in _dl_open (file=0xffffcfa0 "/home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so", mode=-2147483646, caller_dlopen=0x8049555 <Sys_LoadModule(char const*)+181>, 
    nsid=-2, argc=1, argv=0xffffd5c4, env=0x8052bb0) at dl-open.c:884
#30 0xf788131c in dlopen_doit (a=0xffffc75c) at dlopen.c:56
#31 0xf7fca52d in __GI__dl_catch_exception (exception=0xffffc6c4, operate=0xf78812a0 <dlopen_doit>, args=0xffffc75c) at dl-catch.c:237
#32 0xf7fca659 in _dl_catch_error (objname=0xffffc714, errstring=0xffffc718, mallocedp=0xffffc713, operate=0xf78812a0 <dlopen_doit>, args=0xffffc75c) at dl-catch.c:256
#33 0xf7880d47 in _dlerror_run (operate=<optimized out>, args=<optimized out>) at dlerror.c:138
#34 0xf78813e8 in dlopen_implementation (dl_caller=<optimized out>, mode=2, file=0xffffcfa0 "/home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so") at dlopen.c:71
#35 ___dlopen (file=0xffffcfa0 "/home/user/.local/share/Steam/steamapps/common/Half-Life/hw.so", mode=2) at dlopen.c:81
#36 0x08049555 in Sys_LoadModule (pModuleName=0x804a068 "hw.so") at ../public/interface.cpp:159
#37 0x08049017 in main (argc=1, argv=0xffffd5c4) at ../launcher/launcher.cpp:427

Here's the offending line: https://github.com/mirror/libX11/blob/master/src/OpenDis.c#L241

I suspect if I go further fixing code, this assertion will pop up in another descendant library of hw.so and so forth, so I stopped with this stack dump.


So, put short, malloc() fails pretty much globally for some reason. It might be a bug with glibc, or, albeit much less likely, a bug with the elf loader. However, I think this might have something to do with how dlopen() gets called (and/or how modules get set up for loading) on my system.

This fails on Arch Linux 6.2.8 running KDE Wayland (and also X11), but works as expected on Arch Linux 6.1.23 running XFCE X11. SELinux and other nuisances aren't running in either environment.

It would be interesting to see whether this issue already occurred in some other Steam game and whether it was fixed and how.

ghost commented 1 year ago

Update on this. User kimixa on HN found out what's causing this. Posting a part of it here as well:

that's exactly the sort of error you get if something has written just out of bounds on a malloc'd chunk - it clobbers the allocator's internal state, which appears to be what that assert() is checking.

It's probably an allocation before the failing one that is being misued - so the backtrace pointing to openal doesn't necessarily mean it's openal's fault.

Running with valgrind or another heap memory checking tool will probably be helpful to track down that particular linked bug.

...

For reference:
  ==27467== Invalid write of size 2
  ==27467==    at 0x406526A: GetSteamContentPath()
  (pathmatch.cpp:523)
  ==27467==    by 0x4065927: pathmatch(char const*, char\*,
  bool, char*, unsigned int) [clone .part.1] (pathmatch.cpp:594)
  ==27467==    by 0x4066849: pathmatch (pathmatch.cpp:541)
  ==27467==    by 0x4066849: CWrap (pathmatch.cpp:685)
  ==27467==    by 0x4066849: __wrap___xstat (pathmatch.cpp:907)
  ==27467==    by 0x406294A: stat (stat.h:455)
  ==27467==    by 0x406294A: CFileSystem_Stdio::FS_stat(char const*, stat*) (FileSystem_Stdio.cpp:225)
  ==27467==    by 0x4060819: CBaseFileSystem::AddPackFiles(char const*) (BaseFileSystem.cpp:1325)
  ==27467==    by 0x4060AA4: CBaseFileSystem::AddSearchPathInternal(char const*, char const*, bool) (BaseFileSystem.cpp:254)
  ==27467==    by 0x4060B37: CBaseFileSystem::AddSearchPath(char const*, char const*) (BaseFileSystem.cpp:186)
  ==27467==    by 0x8049003: main (launcher.cpp:413)
  ==27467==  Address 0x45e5f4e is 30 bytes inside a block of size 31 alloc'd
  ==27467==    at 0x4041714: malloc (vg_replace_malloc.c:393)
  ==27467==    by 0x4357C4A: strdup (strdup.c:42)
  ==27467==    by 0x42F1A76: realpath_stk (canonicalize.c:410)
  ==27467==    by 0x42F1A76: realpath@@GLIBC_2.3 (canonicalize.c:432)
  ==27467==    by 0x406525B: GetSteamContentPath() (pathmatch.cpp:520)
  ==27467==    by 0x4065927: pathmatch(char const*, char\*, bool, char*, unsigned int) [clone .part.1] (pathmatch.cpp:594)
  ==27467==    by 0x4066849: pathmatch (pathmatch.cpp:541)
  ==27467==    by 0x4066849: CWrap (pathmatch.cpp:685)
  ==27467==    by 0x4066849: __wrap___xstat (pathmatch.cpp:907)
  ==27467==    by 0x406294A: stat (stat.h:455)
  ==27467==    by 0x406294A: CFileSystem_Stdio::FS_stat(char const*, stat*) (FileSystem_Stdio.cpp:225)
  ==27467==    by 0x4060819: CBaseFileSystem::AddPackFiles(char const*) (BaseFileSystem.cpp:1325)
  ==27467==    by 0x4060AA4: CBaseFileSystem::AddSearchPathInternal(char const*, char const*, bool) (BaseFileSystem.cpp:254)
  ==27467==    by 0x4060B37: CBaseFileSystem::AddSearchPath(char const*, char const*) (BaseFileSystem.cpp:186)
  ==27467==    by 0x8049003: main (launcher.cpp:413)

If we reference reverse-engineered HLDS code where an early version of the pathmatch.cpp file is available, we see the following code which calls GetSteamContentPath: https://github.com/dreamstalker/rehlds/blob/master/rehlds/filesystem/FileSystem_Stdio/src/pathmatch.cpp#L575-L600

But in Source SDK this is done in a different way without messing with malloc()'ed pointers: https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/tier1/pathmatch.cpp#L551-L580

I compiled the filesystem_stdio library from the reHLDS project with the pathmatch function from the Source SDK and I can confirm that I no longer crash before the game loads. But now I get to the standard blue background screen and then I hit another memory bug. Here's the Valgrind output as a gist: https://gist.github.com/10669836/6ec01d2a943037cb53d7549fd78621ab

An error message also gets printed to stdout: Error loading 'resource/trackerScheme.res'

// In CBaseUI::Start
// ...
if (!vgui2::scheme()->LoadSchemeFromFile(resource/trackerscheme.res", "BaseUI")) {
    gEngfuncs.Con_Printf("Error loading '%s'\n", "resource/trackerScheme.res");
}
// ...
// afterwards come calls to CounterStrikeViewport::Start, etc.

And LoadSchemeFromFile looks like this:

//-----------------------------------------------------------------------------
// Purpose: loads a scheme from disk
//-----------------------------------------------------------------------------
HScheme CSchemeManager::LoadSchemeFromFile(const char *fileName, const char *tag)
{
    // Look to see if we've already got this scheme...
    HScheme hScheme = FindLoadedScheme(fileName);
    if (hScheme != 0)
        return hScheme;

    KeyValues *data;
    data = new KeyValues("Scheme");

    data->UsesEscapeSequences( true );  // VGUI uses this

    bool result = data->LoadFromFile((IBaseFileSystem*)filesystem(), fileName );
    if (!result)
    {
        data->deleteThis();
        return 0;
    }

    CScheme *newScheme = new CScheme();
    newScheme->LoadFromFile( fileName, tag, data );

    return _scheme.AddToTail(newScheme);
}

So, again, we're back to filesystem code. Since I'm using a third-party replacement library for filesystem_stdio, I see no point in opening another issue without someone else from Valve confirming this (since with the official binary I can't even get that far). On the bright side, at least one nasty bug has been discovered with an easy fix.

nipnipj commented 1 year ago

Same here, on cs1.6, Process 6345 (hl_linux) of user 1000 dumped core.. I'm using linux mint 20.3 Almost full log:

Stack trace of thread 6351:
#0  0x00000000e8845461 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0xd39461)
#1  0x00000000e88342f5 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0xd282f5)
#2  0x00000000e83bdfe5 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x8b1fe5)
#3  0x00000000e83be456 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x8b2456)
#4  0x00000000e83be71d n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x8b271d)
...
#58 0x00000000e8f888a3 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x147c8a3)
#59 0x00000000e8dd52f9 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x12c92f9)
#60 0x00000000e89c7a39 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0xebba39)
#61 0x00000000e8fec492 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x14e0492)
#62 0x00000000e8f8736b n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x147b36b)
#63 0x00000000e8f877f2 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libcef.so + 0x147b7f2)

Stack trace of thread 6349:
#0  0x00000000f7f16d99 __kernel_vsyscall (linux-gate.so.1 + 0xd99)
#1  0x00000000f7cc3796 do_futex_wait.constprop.0 (libpthread.so.0 + 0x11796)
#2  0x00000000f7cc38a7 __new_sem_wait_slow.constprop.0 (libpthread.so.0 + 0x118a7)
#3  0x00000000f493e3b4 n/a (/home/cuysaurus/.local/share/Steam/steamapps/common/Half-Life/libSDL2-2.0.so.0 + 0xa73b4)
ghost commented 1 year ago

@SGmuwa @kellerman @ry755 @aguadecoco1301 @thaewrapt @kkartaltepe @nipnipj Hopefully you don't mind the ping, but I've solved this issue and am able to play Counter-Strike again without issues. I'll explain how you can do it as well.

In order to get your game up and running again, you will have to (re-)compile filesystem_stdio.so with some fixes. This means you will have to replace a binary the game uses, which may or may not be checked by Valve Anti-Cheat. So, short disclaimer - I'm not responsible if you get VAC banned. [But to be honest, the chances of this happening are next to none.]

[Option 1] Copy-paste steps (one line at a time in your terminal):

git clone https://github.com/10669836/rehlds.git
cd rehlds
git checkout fix/filesystem
./build.sh --jobs=$(nproc) -DCMAKE_BUILD_TYPE=Release -DDEBUG=False -DUSE_STATIC_LIBSTDC=True
cp ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so.original
cp ./build/rehlds/filesystem/FileSystem_Stdio/filesystem_stdio.so ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so

You'll need gcc for compiling and cmake, and potentially some other utility as well.

You can see the changes here: https://github.com/dreamstalker/rehlds/pull/972 (or in the git .patch file from the release link below)

[Option 2] For those who want to live the dangerous life and want to trust random binaries off the internet, you can download the fixed and compiled filesystem_stdio.so binary from here: https://github.com/10669836/rehlds/releases/tag/fix-fs

I would recommend that you compile it yourself, but your choice. But, in case you just downloaded my .so, then you'll have to create a copy of the original .so, which is located at ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so (i.e. rename it to filesystem_stdio.so.original) and then place my .so in the location where the original was.

That's it. Huge thanks to the reHLDS project authors and kimixa from HN.

Have fun, everyone.

PS. This works for DOD and other HL1 games as well.

xxkfqz commented 1 year ago

Bug still presents today. New instruction

git clone https://github.com/dreamstalker/rehlds.git
cd rehlds
wget https://github.com/dreamstalker/rehlds/pull/972.patch
patch -p1 < 972.patch
./build.sh --jobs=$(nproc) -DCMAKE_BUILD_TYPE=Release -DDEBUG=False -DUSE_STATIC_LIBSTDC=True
cp ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so.original
cp ./build/rehlds/filesystem/FileSystem_Stdio/filesystem_stdio.so ~/.local/share/Steam/steamapps/common/Half-Life/filesystem_stdio.so

Also in case of broken URLs again i create fork with applied patch here. Precompiled lib also available

mathew2214 commented 1 year ago

confirmed still happening as of august 29 2023. compilation instructions from https://github.com/ValveSoftware/halflife/issues/3158#issuecomment-1674228015 do not work. precompiled library linked does allow the game to launch. but game does not follow xrandr primary monitor setting. likely an unrelated bug.

PoorPocketsMcNewHold commented 1 year ago

confirmed still happening as of august 29 2023. compilation instructions from #3158 (comment) do not work. precompiled library linked does allow the game to launch. but game does not follow xrandr primary monitor setting. likely an unrelated bug.

I had revert the inclued patch as it was already applied upstream https://github.com/xxkfqz/rehlds/commit/624f37fba1c4fd4bc443e3ec10435d6e9e50b5d3 So, go build directly the file after cloning the repository. Here's my compiled filesystem_stdio.so binary. Build on Solus x86_64 with gcc. Also inclued the original file for good measure.

kuche1 commented 10 months ago

Just tested this today and it seems to be working now.