lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 9/21/2016 2:44 AM, Christian N. wrote:
Am 21.09.2016 um 01:33 schrieb Thijs Schreijer:
Repeating; mixing runtime ‘seems’ to work, until it doesn’t. You’ll
get sporadic and hard to trace crashes. Search the archives, plenty of
others went before you…

In my (too) long experience with Windows starting with Windows 3.0 as a developer and Windows 2.0 as a casual user, this is what happens. Periodically there are efforts to improve the situation. Sometimes things even get peaceful for a while. But then something breaks and it is very difficult to debug.

First, even though I argue that in the case of Lua, there is no problem
with mixed CRTs, I do so mostly on theoretical grounds (though I did
have success mixing a small MSVC 2015 executable and the MSVC 2013 Lua
DLL). I do not recommend mixing CRTs if at all possible.

For released products not mixing CRTs is the only sane answer. If you are building a product top to bottom, just don't do it.

Use DEPENDS.EXE (delivered with VS, newer versions from its developer at their web site) to see what DLLs are actually loaded to make sure you did it right. Don't fret too much when one official CRT loads another, that has often been the case, and should generally be assumed to be by design.

But I have read your MSDN link
( and if
anything, it seems to support my arguments:

Each copy of the CRT library has a separate and distinct state.

True, but there is a case that is being overlooked: namely accidentally loading more than one build of the Lua interpreter. That is almost certainly a pathway to madness.

If you use the Lua 5.1 distributed as Lua for Windows which is entirely linked to one version of the CRT, and then add a module you compile yourself linked to another, you might be ok if you successfully keep all CRT property isolated.

But when you load a module that has a different build of Lua linked, possibly as a result of frustration when trying to get your module to build at all, you will have trouble. The most obvious source of trouble (that has a really really really obscure symptom) results from the fact that the value `nil` is at the core a singleton static data structure in the Lua core. When there are two Lua cores, `nil` from core A is not the same as `nil` from core B and all kinds of strange things will happen.

The problem is not that it will fail.

The problem is that it will seem to work. Until it fails.

We've had long threads on debugging this kind of problem on this list in the past. In the long run, having multiple DLLs loaded that "do the same thing" often leads to very mysterious symptoms that only happen when the perfectly working application is demonstrated before upper management, your most important customer, or left in Antarctica to gather data over the winter.

Although this tread has been implicitly discussing the issue from the Windows point of view, this can happen in *nix land too. There, the usual cause is static linkage when dynamic should be used, and usually not the result of multiple CRTs because having more than one is not a common configuration in *nix.

Tangetially related: With the ucrtbase.dll since Windows 10 / VS 2015,
the operating system becomes a CRT delivery channel again (cf. the
oldnewthing blog article mentioned previously in this thread). This CRT
is announced to be stable across major VS versions
and will thus hopefully tame the Windows CRT jungle.

I've been hearing promises to tame DLL Hell since shortly after Windows was born. I sure hope it happens someday. At least from what I've read about the recent promise to "fix" the CRT, it does sound like a group at MS has taken ownership of that specific niche of the problem and has a plan that might succeed. Until it fails. ;-)

Ross Berteig                     
Cheshire Engineering Corp. 
+1 626 303 1602