Detecting multiple linked C runtime on windows

It's rather unlikely that you could successfully statically link against multiple C runtime libraries - you would run into many symbol definition conflicts which would at least produce voluminous warnings, and only a reckless engineer would ignore them.

With depends, I would make sure to use the dynamic profiling option, to check all dependencies for dynamic CRTLs they load. If doesn't turn up anything, I suspect your problem is elsewhere.

I would suspect your problem is elsewhere in any case, though, as DLLs with C-level APIs shouldn't, as a rule, rely on shared state in the CRTL - most commonly the memory allocator - and should have adopt a standardized protocol for cross-API memory management, such as caller-allocates, callee-uses, or passing in memory allocation callbacks, etc. In other words, multiple CRTLs in the same process is normally not a problem due to correct use of a memory management protocol.

For transient failures, I would suspect multithreading or heap corruption.

I will look into the dynamic profiling option, thanksConcerning the shared state of CRLT, I don't think I can do anything about it. It is for a python extension, and I simply do not control anything on the memory allocation part (refcounting). I am surprised by your claim that multiple CRT are not a problem - I am far from a windows specialist, but I have consistently read that it should be avoided from quite a few sources. I understand it can be avoided by being careful, but I don't think that's doable in my case (as I don't control every part of the final executable).

David Cournapeau 2009-06-07 11:24:52

Most of the time that you use a DLL on Windows, you don't have the source and can't control what runtime library it's using. It isn't like Linux, where there is the GNU C library, and every shared library can (normally) trust that malloc resolves to the same allocator across the process. Moreover, DLLs may be written in different languages; a Pascal DLL being used in a C EXE, or vice versa, can't share runtime libraries, since they have different requirements. Thus a memory management convention or protocol needs to be followed.

Barry Kelly 2009-06-07 17:15:14

I finally managed to get a stack trace, and the problem is indeed a FILE* passed across DLL boundaries. So I guess I will have to do without somehow.Would you know of any reference concerning protocol for dll boundaries on windows ? I am really unfamiliar with the matter, and I am afraid I will need to deal with it at several places in the codebases I am working on ?

David Cournapeau 2009-06-27 09:13:37

Passing a FILE* across is OK, *so long* as the code on the other side *calls back* in order to fread / fwrite etc. In other words, you need to use a callback table, and treat the FILE* as an opaque cookie. If the code on the other side mixes the FILE* with other FILE* that didn't pass the boundary, you'll have to more refactoring; you could consider e.g. OR-ing in a bit to FILE* values that get passed in, routing all file (f*) operations through simple check functions which test for the bit and choose the CRTL or callback function as appropriate.

Barry Kelly 2009-06-27 11:23:14

Since FILE* will be at least dword-aligned in 99.999% of modern CRTLs, the least significant bit can be ORed in, making the FILE* value odd.

Barry Kelly 2009-06-27 11:24:21

ansaurus

tags:

views:

answers:

Detecting multiple linked C runtime on windows

related questions