> El 06/09/2010 03:44 p.m., Mikhail Gusarov escribió:
>
> Very likely it is well-known problem malloc-in-EXE-free-in-DLL under
> Win32. Try to provide your own alloc/free/realloc functions to
> libssh2_session_init_ex, which just forward calls to malloc/free/realloc.
On 6 September 2010 21:02, Ezequiel Ruiz <eruiz_at_barcelona04.com> wrote:
> You're right. I've changed the memory allocator and the problem disappeared!
> I can't believe MSVC is still having this kind of limitations.
This isn't an MSVC problem or even a Windows problem though it is
often reported that way. It will happen with _any_ compiler on _any_
OS if two shared libraries are linked against different versions of
the C runtime and objects owned by one runtime are shared with the
other. The reason this seems like a Windows problem is that this
mixed-runtime situation is common on Windows but rare on Linux.
Therefore never:
- allocate memory in one module (DLL/shared library) and free it in another
(your current problem). This adds an entry to the heap table in one loaded
runtime and tries to remove the entry (which won't exist) in another
runtime's table. Crash!
- pass a FILE* handle created by one runtime across a module boundary
into another. When the second module uses it it will try to update the entry
in the file handle table which doesn't exist in that runtime
instance. Crash!
NOTE: libssh2's API includes several functions that take a FILE* parameter.
Don't use them, especially on Windows unless, you link statically
or are sure your modules are linked against the same version of the
C runtime.
Alex
-- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2010-09-06