Ubuntu - winetricks fails to install dotnet with sbrk() error

[stubkan]

I'm making this issue as I cannot find a single mention on the internet that references the sbrk() error I'm constantly getting.

Whenever I try to install dotnet48 into a proton prefix with winetricks it throws errors and aborts. If I change the proton or eggroll proton version, wine version, winetricks version, install method etc - it will output different dotnet abort error codes but each time there are sbrk() errors that say.

sbrk() failure while processing tunables

Sometimes it says it once, sometimes it says it 5 times. There are also some other errors that come up, but they seem normal - as I've seen them on other peoples logs.

I've tried for a few days, with various different driver versions, proton versions, wine/winetricks versions - I've updated my system, updated graphics drivers, At a loss now, cos I have absolutely no idea what is wrong.

[stubkan]

Attempt to install into proton 7.0 prefix

Attempt to install into regular wine prefix gives a large wall of sbrk() errors

Trying via the GUI has the same effect, but again with different error messages

[austin987]

Something is broken on your system. Maybe bad ram? Try running memtest.

[stubkan]

I ran memtest86 for 2 hours, three passes , no errors. I think if it was something like that, I'd be seeing glitches elsewhere in my system, but it appears this is the only place. I can use proton/wine properly in other applications without problems as well.

[stubkan]

If it was a memory fault, then wouldn't the error occur intermittently, as different bytes are used at any time - as the data blocks are cycled, so a regularly occuring (if somewhat amorphous) error would not indicate a likely memory fault, but a fault elsewhere?

Regardless, I opened the laptop and swapped memory sticks out, just in case. More attempts.

Install dotnet into vanilla wine prefix via GUI

Executing load_winxp
Executing wine winecfg -v winxp64
sbrk() failure while processing tunables
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: Internal error.

warning: Note: command wine winecfg -v winxp64 returned status 1. Aborting.

install dotnet into prefix via command line

Preparing: C:\598a95d7-a413-4462-9e1f-ba74e93eda39\netfx_Extended.mzz...
wine: Unhandled exception 0xe06d7363 in thread 114 at address 7B0111B7 (thread 0114), starting debugger...
Unhandled exception: C++ exception(object = 0x0061f594, type = 0x1009be00) in 32-bit cod
e (0x7b0111b7).

System information:
Wine build: wine-7.0 (Staging)
Platform: i386 (WOW64)
Version: Windows XP
Host system: Linux
Host version: 5.4.0-121-generic

warning: Note: command /home/stubkan/.local/share/Steam/compatibilitytools.d/GE-Proton7-24/files/bin/wine dotNetFx40_Full_x86_x64.exe /q /c:install.exe /q returned status 99. Aborting.

install dotnet into proton prefix via script
new error this time, kernel32.dll ??

wine: could not load kernel32.dll, status c0000135
wineserver: using server-side synchronization.
wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
sed: -e expression #1, char 0: no previous regular expression

Also the sbrk turns up if I try to follow some instructions I found to set up a new prefix

stubkan@Legion:~$ mkdir -p ~/myapp/prefix
stubkan@Legion:~$ 
stubkan@Legion:~$ cd myapp/
stubkan@Legion:~/myapp$ cd ..
stubkan@Legion:~$ export WINEPREFIX=$HOME/myapp/prefix 
stubkan@Legion:~$ export WINEARCH=win32
stubkan@Legion:~$ export WINEPATH=$HOME/myapp 
stubkan@Legion:~$ wineboot --init
sbrk() failure while processing tunables
stubkan@Legion:~$ winetricks
Executing mkdir -p /home/stubkan/myapp
Using winetricks 20220411-next - sha256sum: 2f0b78b3be1ce83525010c756bc631a50a5dd5cf1c55a1217dde51805001327c with wine-7.0 and WINEARCH=win32
winetricks GUI enabled, using zenity 3.32.0
stubkan@Legion:~$ 

[Chiitoo]

The 'sbrk() failure while processing tunables' seems to come from glibc [1], and seems like it could indeed indicate some kind of a problem with regards to memory, but yeah, usually bad RAM means random errors (but not always... fun!).

The specific error spot was later modified [2] and doesn't exist with my current build (glibc-2.35) at all.

What kind of a system is this? Anything self-compiled or all distribution (which version of Ubuntu?) packages?

1. https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a059f9505bbef1f22c6f52798a74184632929145
2. https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b05fae4d8e34604a72ee36d2d3164391b76fcf0b

Edit: Hit the send-comment button accidentally using some keyboard shortcut(?)...

[stubkan]

Thanks for that. I'll try reinstalling my glibc (though it seems I have libc not glibc) and see if anything changes.

This is my system

I dont generally mess with the system, but who knows, I might have changed something at some point as theres always something that needs fixing at some point and the systems been live a year or so

[stubkan]

I do have Visual Studio Code and Unreal Engine on the system and have been compiling c# for various games, I might have changed the glibc/libc version while getting those things working

[stubkan]

It seems Ive got 2.31 installed, though thats from 2020, and it is up to v2.35 now. According to this post

https://askubuntu.com/questions/1389796/how-to-install-a-libc6-version-newer-than-2-31-on-ubuntu-20-04-focal-fossa

Updating it is a bad idea... Not sure if it'll even help fix this issue.

EDIT

I force-reinstalled the libc6 packages, still getting sbrk error

[Chiitoo]

Generally updating glibc is okay, but only if everything else in the system will be fine with it, which probably isn't the case with Ubuntu-like distros (older things often break with new glibc).

Going backwards is what will even more easily break things though!

With Ubuntu and such I think it's best to stick to what you get from the supported repositories, so if you're not using any weird "ppa" sources and are up-to-date, this should be re-produceable pretty easily with knowing the version of the distribution and all, unless it's a hardware issue.

[Chiitoo]

Oh and I'm not saying at all that the issue lies within glibc, but something makes that part of the code there trigger, and I don't have immediate ideas why that would be aside from running out of RAM somehow...

[stubkan]

You talked about weird PPAs so I looked at my PPAs to check if I some weird ones to remove and I've found out that my glibc comes directly from a PPA by slonopotamus who has compiled a custom version of glibc in order to tackle a bug with Unreal Engine being unable to handle large amounts of files greatly slowing load times. I subscribed to that, as I was using Unreal Engine and it helped a lot.

But now I think this is the likely culprit - I'll go through the process of removing that PPA and reinstalling official glibc and see if things change.

[Chiitoo]

Do make some backupses because as I mentioned, downgrading glibc will easily break things, although I'm not sure how much so it will be in binary distros (I use a source-based Gentoo one myself, so everything gets compiled against the current glibc installed).

[stubkan]

Yeah I got some scary messages but I carefully downgraded each package to the main distro version, seems like it is back to official repo packages now...

I followed this

 Install the following packages:                                            
 libc-bin:i386 [2.31-0ubuntu9.9 (focal-updates)]                          
 libc-dev-bin:i386 [2.31-0ubuntu9.9 (focal-updates)]                      

 Keep the following packages at their current version:                      
 libcrypt-dev [1:4.4.10-10ubuntu4 (focal, now)]                           
 locales [2.31-0ubuntu9.9dso1 (now)]                                      

 Downgrade the following packages:                                          
 libc6 [2.31-0ubuntu9.9dso1 (now) -> 2.31-0ubuntu9.9 (focal-updates)]     
libc6:i386 [2.31-0ubuntu9.9dso1 (now) -> 2.31-0ubuntu9.9 (focal-updates)]
 libc6-dev [2.31-0ubuntu9.9dso1 (now) -> 2.31-0ubuntu9.9 (focal-updates)] 

 Leave the following dependencies unresolved:                               
 gdb recommends libc-dbg    

Bad news is, sbrk errors are still there.

Do I have to reinstall other software such as wine from scratch, because they were compiled when installed with the non-official glibc?

[Chiitoo]

I'd assume a bit that you'd get pre-compiled packages in any case, unless you're actually compiling them at any stage. The package manage should... SHOULD make sure things work together okay, but I'm really not too familiar with Ubuntu and the likes...

[austin987]

@stubkan, if you have another partition/hdd/usb, it would be worth trying a stock install of whatever version of ubuntu you're running, so that you can try a clean setup on the same hardware, to narrow down if it's a hardware/software issue.

[stubkan]

Well, that took a long dang time, but I got a USB live usb set up of the system - Ubuntu Mint 20.1 and installed wine64 7.0 then winetricks.

Set up a new prefix successfully then with winetricks installed dotnet 4.0 successfuly but after several hours of non stop scrolling errors I figured something was off and stopped it, winetricks was the 2020 version so I self updated it and did it again.

It installed dotnet 48 successfully with no fuss. I dont think it's a hardware issue.

I ran system update and upgrade and got about 2 or 3 GB of updates which took a long while, so the liveusb should be current with my system. Installed mono as well before wine would work.

[stubkan]

I could use the liveusb to install dotnet into the one prefix I need it in and copy it over and hope that is enough.. Though this sbrk thing bugs me and may be causing problems elsewhere... I'd like the system to be clean.

I suspect in newer glibc versions they have removed the sbrk function and use another method - Maybe I can run the newer glibc somehow and see if that error still comes up, though I have no idea how to go about setting that up.

[austin987]

Well, one thing is clear, it's not a winetricks issue, but an issue with your system.

Your distro or whoever provided the PPA that you got gliibc from may be able to provide better help.

[stubkan]

There was a line in .profile that said

export GLIBC_TUNABLES=glibc.rtld.dynamic_sort=2

Removing the line fixed the issue. I think it was a line that went in to fix Unreal Engine issues.

[Chiitoo]

A-ha!

Good to know. Thank you for sharing!

[austin987]

There was a line in .profile that said

export GLIBC_TUNABLES=glibc.rtld.dynamic_sort=2

Removing the line fixed the issue. I think it was a line that went in to fix Unreal Engine issues.

Glad you got it fixed.

If it's still needed for Unreal, I'd suggest removing it from ~/.profile, and instead make a wrapper script, so that you only export that variable when running Unreal, and avoid affecting the rest of your system.