@dotnet-policy-service agree

Thanks @jo-oe

What's actually blocking this right now? the azure build logs are gone, so i can't see what failed. I'm stuck with fedora having merged a fix for their packages, but they don't target the required dotnet runtime version, and the mono centos8 repository, which otherwise has the right target runtime support, doesn't have this fix in it.

What's actually blocking this right now? the azure build logs are gone, so i can't see what failed. I'm stuck with fedora having merged a fix for their packages, but they don't target the required dotnet runtime version, and the mono centos8 repository, which otherwise has the right target runtime support, doesn't have this fix in it.

@karlp I suggest that you report this issue downstream to these distributions.

Getting this issue merged here (upstream) won't guarantee these distributions will have the fix.

When I say the "mono centos 8 repo" I actually mean this one: https://download.mono-project.com/repo/index.html from mono itself. My distro (fedora in this case) has already merged this fix, but their package doesn't target the "right" runtime, so I can't use it to build Renode So yeah, I'm hoping to get it into a mono tree at some point, not just downstreams.

Ping @madewokherd - could this be merged in the new upstream? It is not in 6.14.1. Thanks!

Is this solved by zlib-ng/zlib-ng#1713?

Is this solved by zlib-ng/zlib-ng#1713?

@fweimer-rh IMHO, it only works around the issue here.
The zlib documentation explicitly says:

The application must initialize zalloc, zfree and opaque before calling the init function.

Source: https://www.zlib.net/manual.html#Usage

There is a chance this is going to crash again if mono doesn't fix it.