GIMP crash caused by setlocale bug on Windows (via Exiv2 in the call stack)

[Wormnest]

Describe the bug

We (GIMP) have received several crash issues on Windows that proved difficult to diagnose. Our Ms Store handler finally received a crash log that indicates a possible relation to exiv2.

In other cases the telltale sign is libc++abi: terminating due to uncaught exception of type std::bad_alloc: std::bad_alloc, which at this time we are assuming to be the same issue. (Most of GIMP itself is C, not C++)

To Reproduce

Steps to reproduce the behavior:

1. GIMP's Windows developers have not been able to reproduce on their systems. We depend on users reporting this.
2. They try to load an image and then they get a crash, usually without details.

Expected behavior

Loading of images including loading their metadata through gexiv2 -> exiv2 succeeds.

Desktop (please complete the following information):

• OS and version: so far this seems to be Windows only
• Exiv2 version and source: GIMP 3.0.0 and 3.0.2 use 0.28.5, RC3 where this also happened may have used an earlier version, all supplied by MSYS2, CLANG64 profile.
• Compiler and version: clang as provided by MSYS2
• Compilation mode and/or compiler flags:

Additional context

Looking at the trace linked above, I wonder if this could be related to the code that replaced the Data handling regex, maybe in combination with locale handling? Just a wild guess, I'm not a C++ expert.

I wish we could give more details, but I thought it good to make you aware of this.

[brunvonlope]

If someone needs it, I can send the memory dump, minidump and other files we got from Windows tools about this bug.

[kevinbackhouse]

Are you able to reproduce this in GIMP with this image? https://gitlab.gnome.org/GNOME/gimp/-/issues/12626#note_2368064

I've run exiv2 on that file from a Linux command line and it looks very boring: I don't see any weird values that would be likely to trigger a bug. So I'm wondering if the bug only happens with the larger 347 MB file that's mentioned in the thread.

[kevinbackhouse]

By the way, I don't think this is necessarily date-related. Is that hypothesis based on the mention of ZNK5Exiv29Exifdatum8toStringEv in the stack trace?

[Wormnest]

Are you able to reproduce this in GIMP with this image?

No, but GitLab removes most metadata due to privacy concerns.

By the way, I don't think this is necessarily date-related. Is that hypothesis based on the mention of ZNK5Exiv29Exifdatum8toStringEv in the stack trace?

Yes, based on that together with knowing that the regex was replaced fairly recently, but as I mentioned above, just a wild guess since I've only glanced at exiv2 code a few times.

[kevinbackhouse]

Are you able to reproduce this in GIMP with this image?

No, but GitLab removes most metadata due to privacy concerns.

I'm happy to take a look, but I do need access to the image that causes the problem.

[neheb]

No surprise here. Regex replacement is not a simple task. The code works well enough to only pass the test suite.

[Matsemann]

It happens for any png I try to load. I just made a white 16x16 px png in photopea and zipped it for upload here:

16x16.zip

no special metadata afaik.

Just clicking the png file in the file selector (so even before opening, but I guess it tries to make a preview) crashes gimp 3.0.2-1.

$ gimp-3.exe --verbose --console-messages
> .....
> libc++abi: terminating due to uncaught exception of type std::bad_alloc: std::bad_alloc

[jone-l]

If this is a date issue, it might be related to regional settings and the various date formats. I was getting constant crashes with Gimp 3.0.2-1 (on Windows 11) today, both when trying to save/export anything, or loading an image with the open dialog. Same message as described above:

libc++abi: terminating due to uncaught exception of type std::bad_alloc: std::bad_alloc

I'm using Norwegian regional settings, so todays date would be written as 13.05.2025 changed to US regional format, 5/13/2025 and all the open/save/export crashes went away.

If it's trying to parse the 13th as month 13, I'm guessing that could potentially cause issues.

[neheb]

So effectively the same issue as #3264

Had this been backtraced with gdb?

[Matsemann]

Huh, I can confirm. Changing from Norwegian Bokmål (Norway) regional format on my Windows computer to English (United States) allowed me to open files that used to crash. Changing back and restarting gimp they crash again.

[neheb]

Windows 11 has a UTF8 option. Does that also crash?

[Wormnest]

The Norwegian locale possibly points in the direction of this. In GIMP we set UTF-8 in the Windows manifest. I've wanted to make a test build with that reverted, but we have some unrelated issues building with gcc 15.1 that need to be fixed first.

[jone-l]

For the record, Norwegian Nynorsk (Norwegian) seems to work fine (pretty much identical formats as the bokmål one, but no utf-8 chars in name), so I'm using that as a workaround for now.

Aren't many locales with potential problem-characters, but found that these two also seem to cause crashes reliably:

• Dutch (Curaçao)
• French (Côte d'Ivoire)

[brunvonlope]

I've wanted to make a test build with that reverted, but we have some unrelated issues building with gcc 15.1 that need to be fixed first.

@Wormnest You can test the msix by removing the ActiveCodePage there too https://gitlab.gnome.org/GNOME/gimp/-/blob/master/build/windows/store/AppxManifest.xml#L75