Matt G

I'm pretty sure you made the change which added ICODIB. https://sourceforge.net/p/graphicsmagick/code/ci/950d7366f623c020e13f55a3eb88d749323de396/ Adding the alias does fix the issue. Thanks for being so responsive on my questions.

Using 1.3.28. I try to read a Windows icon file and it fails. The problem appears to be that when an icon is detected its magick is changed from ICO to ICODIB in ReadIconImage (icon.c). GetMagickInfo tries to find a coder to handle ICODIB but one hasn't been loaded yet and the name of the module it's in is IM_MOD_RL_dib.dll, not IM_MOD_RL_icodib.dll, so it can't be found by OpenModule (module.c). The only way I see that this could work would be if a DIB was loaded first so that the ICODIB magick...

You're right. I shouldn't have made my statement so broad. I was referring to how the compiler is handling this particular case. When I look at the disassembly for DllMain I see that it pushes 0x104B0 bytes on the stack at the start of the function and pops it at the end. The push isn't conditional. It happens regardless of the values of the parameters. Other compilers or the same compiler with different options may behave differently, but in my case 65K is being put on the stack.

All auto variables in a function are put on the stack regardless of their scope since the function doesn't know whether they'll be used or not. It can't predict what code path will be taken. You might have missed new_path[], which accounts for the other 32K. DllMain doesn't have to be reentrant for DLL_PROCESS_ATTACH since it will only be called once and the process blocks until it returns. Since nothing is being done for DLL_THREAD_ATTACH it is clearly reentrant in that case. I will look at removing...

DllMain (in magick\nt_base.c) declares two large arrays and one smaller array, totalling 65K bytes, as autos so they're allocated on the stack. This is usually OK because the default stack size is 1MB so there's plenty of room for this temporary stack usage. The problem occurs when a thread is created with a very small stack, which can be done via the dwStackSize parameter of CreateThread. We're seeing a case where a thread is created with a 64K stack. The parent process dies with a stack overflow...

Here is my version with the fix for task markers in single-line comments.

Here is my version with the fix for task markers in single-line comments.

I noticed that task markers don't work in single-line comments. Here's a proposed...