Re: Lua app crash with mixed DLLs; advice needed

[Paul K <paulclinger@...>]

Thanks Owen for the detatils and thanks Thijs for a link to a nice
writeup on this issue.

> Whatever the result, it occurs whenever you try to interact with things at
> the C library/C++ library layer between different DLLs compiled with
> different runtime libraries on Windows.

So, what are my options? Why does it seem to work when I use luasocket
compiled with VS from an application compiled by Mingw? Am I just
lucky in this case and my luck may run out with a different
application or is this going to work?

In a more general case, do I need to provide luasocket compiled with
different runtimes for those people who use them? Is there a way to
check for the version of runtime (maybe a windows API call?) such that
I can load an appropriate dll? Or is it sufficient to provide
mingw-linked and MSVCRT.DLL-linked versions and ask users to use
MSVCRT.DLL-linked one if they see strange crashes while debugging? Or
maybe there is something I can change in luasocket to avoid these
issues?

My apologies for all these questions, but I'm flying dark here and
would appreciate any insight into what can be done. Thank you.

Paul.

On Sun, Mar 10, 2013 at 5:18 PM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> Paul K wrote:
>>
>> The question is this: what are the real reasons behind advice to not
>> mix DLLs compiled with different compilers? Why is everything working
>> correctly (even socket.select), but in some (quite rare, but still
>> reproducible) cases things go wrong?
>
>
> MinGW and Visual Studio use different C runtimes (with the exception of the
> combination of MinGW and Visual Studio 6).
>
> Lua file objects wrap C "FILE" streams. Lua Socket sockets are (I assume)
> also implemented on top of these. It probably works mostly for simple cases
> because the Visual Studio C runtime is unlikely to have changed its'
> internal memory layout substantially between versions, but occasionally
> you'll hit on a corner case. For example, if Luasocket needs to get the
> Win32 HANDLE behind a "FILE" object, it will call _fdnum in its' own C
> library (which probably works because of the same structure layout) to get
> the file descriptor number, followed by _get_osfhandle to convert the
> UNIX-style FD number into a Win32 HANDLE.
>
> And this is where it goes wrong, because every C runtime has its own file
> descriptor table, so LuaSocket gets the wrong handle. If you're "lucky" (for
> some definition of lucky) LuaSocket gets the wrong handle and things still
> (sort of, but not really) work, and if you're "unlucky" (which in some
> regards is more lucky, because at least the problem is immediate) you crash
> (perhaps because you go past the end of the file descriptor array in the C
> library).
>
> Whatever the result, it occurs whenever you try to interact with things at
> the C library/C++ library layer between different DLLs compiled with
> different runtime libraries on Windows.
>