Icon.ToBitmap() crashes on linux (likely a gdiplus error)

[mfeemster]

OS: linux mint
Version: latest
.NET: 9

Creating an icon, then attempting to get its bitmap exits with an out of memory exception. I've traced the crash to Image.InitializeFromStream()

int st = Gdip.GdipLoadImageFromDelegate_linux() is called and the return value is checked with:
Gdip.CheckStatus(st);

That last line throws because instead of st having a value of 0, it has a value of 3.

Upon inspecting the icon loading code here @madewokherd :
https://gitlab.winehq.org/mono/libgdiplus/-/blob/main/src/bitmap.c?ref_type=heads
https://gitlab.winehq.org/mono/libgdiplus/-/blob/main/src/icocodec.c?ref_type=heads

It appears the default return value is out of memory for many different operations.

To test, I found an internal method in Icon.Unix.cs named BuildBitmapOnWin32() and made it public just to see what would happen.

var ico = new System.Drawing.Icon("./Icon1.ico");

var bmp1 = ico.ToBitmap();//Crashes
var bmp2 = ico.BuildBitmapOnWin32();//Ok

Note that with regular .NET 9 on windows, this code runs fine.

github disallows attachments of icon files, but you can download the icon that is giving me trouble here:
https://bitbucket.org/mfeemster/keysharp/src/master/Keysharp.Tests/Code/Gui/Icon1.ico

Any help is much appreciated.

[madewokherd]

I see gdip_read_ico_image_from_file_stream initially sets status to OutOfMemory, but it then overwrites status with the result of gdip_read_BITMAPINFOHEADER. The goto's before that appear to be error paths. Other uses of OutOfMemory appear to either be allocation failures or memory size that doesn't fit in 32 bits.

[madewokherd]

Does Image.InitializeFromStream work correctly for this icon file on Windows? If so, I'd say this is a libgdiplus bug.

[mfeemster]

Does Image.InitializeFromStream work correctly for this icon file on Windows? If so, I'd say this is a libgdiplus bug.

Yes, I just pulled the latest of this repo on Windows, built and ran:

var ico = new System.Drawing.Icon("Icon1.ico");
var bmp1 = ico.ToBitmap();

and

var fs = new FileStream("Icon1.ico", FileMode.Open);
var streamImage = System.Drawing.Image.FromStream(fs);

both work fine. So think this is definitely a libgdiplus bug. Can you try to reproduce it on linux with the icon file linked above?

Are you actively maintaining that repo?

[madewokherd]

I don't have much time for it, but I am trying to at least get some bugfixes in libgdiplus for things I see reported.

[mfeemster]

Thanks for looking into it. Should I check your repo or this one for an update?

[madewokherd]

Bug should really be filed on the winehq libgdiplus repo. Or this one could be kept open to track the upstream bug, if preferred.

There's also the question of updating the libgdiplus in nuget System.Drawing. There's already been a new release on Winehq, and I don't know if it's been updated there.

[sancheolz]

If you are talking about a package https://www.nuget.org/packages/System.Drawing.Common, then it does not contain libgidplus.so.

[madewokherd]

Is that just provided by distros then?

[sancheolz]

Yes

[madewokherd]

This ico file is strange. It has a 32-bit bitmap of dimensions 18x72, with data size set to 2736 bytes and no compression. For those dimensions, you should need 4*18*72 = 5184 bytes. It looks to me like libgdiplus calculates the size itself rather than use the size in the file, and thus it tries to read past the end of the file. When it doesn't get enough data, it returns an error.

And yet, somehow Wine's windowscodecs reads it just fine, and it sounds like gdiplus.dll on Windows does too.

[madewokherd]

Ah, height is doubled because the ICO format does that, but libgdiplus seemingly fails to account for this.

[madewokherd]

I made a merge request: https://gitlab.winehq.org/mono/libgdiplus/-/merge_requests/8

[mfeemster]

Thanks and great find! Hopefully they'll accept it and update.

[madewokherd]

The patch turned out to break the tests, and I kinda lost track of this for a while.

It seems the tests have a test icon with a width/height that matches the size in its ICONDIRENTRY and a doubled height in BITMAPINFOHEADER. Your icon has a doubled height in both structures. (Oddly, the test icon has two entries, one of which is 0x0 in ICONDIRENTRY and 256x512 in BITMAPINFOHEADER.)

This suggests that ICONDIRENTRY width/height should be ignored entirely, and the size from BITMAPINFOHEADER should be used. Which is also what Wine's windowscodec does.