Heap corruption

[fiendish]

print(utils.utf8convert(utils.fromhex("FFFAC9636F6D6D2E6368616E6E656C207B20226368616E223A20226774656C6C222C20226D7367223A2022405928405747726F757040592920405931333337204834783072204669656E646973683A2027686D274077222C2022706C61796572223A20224669656E6469736822207DFFF01B5B303B33376D5B1B5B313B33316D61796C6F722D301B5B303B33376D20546865204772616E642043697479206F662041796C6F72201B5B313B33326D45786974733A4E45535755441B5B303B33376D5D205B1B5B313B33366D57697A693A1B5B313B33356D201B5B313B33366D496E636F673A1B5B313B33356D1B5B303B33376D5D201B5B313B33316D54656C6C733A30201B5B6D1B5B303B33376D1B5B303B33376D0A0D")))

in a debug build of MUSHclient raises

The hex is obviously invalid utf8.

[nickgammon]

In this line:

https://github.com/nickgammon/mushclient/blob/master/scripting/lua_utils.cpp#L1122C16-L1122C29

Shouldn't it be:

    int iLen = _pcre_ord2utf (((int) *p, utf8);

Or wouldn't that make any difference? I don't see why we don't get a compiler warning.

It doesn't crash for me, on Windows XP or running under Wine.

[nickgammon]

Or maybe:

    int iLen = _pcre_ord2utf (((unsigned int) *p, utf8);

[nickgammon]

The hex is obviously invalid utf8.

It is supposed to be ANSI code page, and is converted into UTF8.

https://www.gammon.com.au/scripts/doc.php?lua=utils.utf8convert

[fiendish]

oops, right

[nickgammon]

I think the integer promotion should work, and I can't see what is wrong with the code.

[fiendish]

I'm working on a PR to get debug builds uploaded

[nickgammon]

I can't get that to fail, even compiling under Visual Studio 2019, under Windows 10. However I note that the memory used by the app increases by 1 MB every few seconds, even with no worlds open.

After 7 minutes of doing nothing I am up to 690 MB.

So, something is wrong.

[nickgammon]

The task manager shows a similar increase when running without debugging.

[fiendish]

Bizarre indeed.

[fiendish]

I looked into the memory leak finally, and it looks like it's only in the debug builds. Probably that means something about debug allocators that we likely don't need anyway.

[fiendish]

Indeed, the runaway memory growth looks to be caused by the use of SET_CRT_DEBUG_FIELD( _CRTDBG_DELAY_FREE_MEM_DF );