1

I have some problems with one of the projects I am working on on windows (64 bits). The program sometimes crash, sometimes does not, and I suspect the problem to be linked with multiple linked C runtime. How can I detect this on windows ? I tried with depends.exe, but it did not report the CRT

David Cournapeau
  • 78,318
  • 8
  • 63
  • 70

1 Answers1

3

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.

Barry Kelly
  • 41,404
  • 5
  • 117
  • 189
  • I will look into the dynamic profiling option, thanks Concerning 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 Jun 07 '09 at 11:24
  • 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 Jun 07 '09 at 17:15
  • 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 Jun 27 '09 at 09:13
  • 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 Jun 27 '09 at 11:23
  • 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 Jun 27 '09 at 11:24