RSA Interview Question
Software Engineer / Developers1) It depends on how the DLL was built (and it should be documented). If it is built to use the shared C runtime (the msvcrt.dll, if you are using a Microsoft compiler), and so is your app, then it is okay to delete / free. But otherwise (DLL uses static runtime) you will very likely be getting a crash because the free or delete call in the app attempts to release memory off a different heap that the one where it was allocated from.
It is a better design to have the DLL provide factory methods, and for the classes in that DLL to have a virtual Release method (it is crucial for the method to be virtual).
2) There may be an uninitialized memory bug in the DLL. In debug mode you tend to get everything zeroed out by the runtime. Or maybe the application releases the DLL (by calling FreeLibrary) but keeps referencing objects or functions in the DLL (in debug mode that memory may not be reused right away). There may be some assert(...) side effects, or the memory layout of some class is not the same in debug versus release.
1. Memory allocated by a dll is in the user process space, so if the user releases the memory using the corresponding operator i.e. new/delete, malloc/free. But if they are mixed then behavior would be to be best said undefined. It would be better if dll provides a function to release/dispose off the allocated memory.
- Samit Sasan May 13, 20092. In my experience if debug works fine but release crashes, then there is some memory related issue would code. We might be overwriting beyond array limits or accessing an uninitialized variable or may be we are writing to memory after its been freed. Debug version code is much more prodigal in this matter, it allocates access memory, so such matter are caught in release versions but go unnoticed in debug.