Running Lua from within a Window Program

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Running Lua from within a Window Program

Christian N.
Am 21.09.2016 um 12:15 schrieb Jerome Vuarand:
> C runtimes are not just a bunch of clean C functions using only stack
> memory. Some might expect their main wrapper to have been called to
> initialize some globals and will break if the exe was linked to
> something else. Some might use thread-local storage in different ways,
> and overwrite each other's memory.

Please see my mail titled "Mixing CRTs on windows" in this thread
regarding that.
While it may be true for other systems, at least on Windows, multiple
CRTs have to be prepared for side-by-side loading (although I have
verified that only for MSVC. It might indeed be different for MinGW).

 > But even with two nice and clean runtimes, the Lua 5.3 API has a FILE*
 > in luaL_Stream (I was under the impression that older Lua version had
 > some FILE* too, but I can't find them now). If your program creates
 > some of these, or if binary modules access some of Lua's own streams,
 > you need to make sure every party involved agree on what FILE*
 > pointers point at.

That is right. If you use luaL_Stream, then you need to use the same CRT.

I agree that mixing CRTs is a bad idea, but technically it should work
for Lua on Windows (except for luaL_Stream, environment variables and
locales).

‒ Christian

Reply | Threaded
Open this post in threaded view
|

Re: Mixing CRTs on windows (was: Re: Running Lua from within a Window Program)

Viacheslav Usov
In reply to this post by Christian N.
On Wed, Sep 21, 2016 at 11:44 AM, Christian N. <[hidden email]> wrote:

> 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 (https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/) and will thus hopefully tame the Windows CRT jungle.

Unfortunately, not in the way it is officially documented. Officially you would still need vcruntimeXXX.dll that are not distributed with the OS,

Unofficially, there is a workaround [1], which makes it possible to use ucrtbase.dll without vcruntimeXXX.dll, but this is still not problem free [2].

Cheers,
V.


Reply | Threaded
Open this post in threaded view
|

Re: Mixing CRTs on windows

Ross Berteig
In reply to this post by Christian N.


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
> (https://msdn.microsoft.com/en-us/library/ms235460.aspx) 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
> (https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/)
> 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                               [hidden email]
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602

Reply | Threaded
Open this post in threaded view
|

Re: Mixing CRTs on windows

Coda Highland
On Wed, Sep 21, 2016 at 2:46 PM, Ross Berteig <[hidden email]> wrote:
> 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.

Until you have to update glibc. >.> I remember going from libc5 to
libc6. THAT was an adventure. The typical advice was "make a backup,
blow away your system, and install fresh."

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Mixing CRTs on windows

Thijs Schreijer
In reply to this post by Ross Berteig

On 21 Sep 2016, at 23:46, Ross Berteig <[hidden email]> wrote:



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.

An alternative (and shameless plug) would be to use the Lua module `pe-parser` [1] (this is a Lua list after all).

Thijs


Reply | Threaded
Open this post in threaded view
|

Re: Mixing CRTs on windows

Ericson Carlos
When I'm lazy I copy a dll from Lua for Windows and drop it into LUA_CPATH.  Works most of the time :)

I got a hunch as long as the dll does all memory allocations via Lua then it works.
12