Subject: [gnuwin32 - Help] RE: libjpeg: crash during call jpeg_read_head - msg#00008

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=4053776
By: tml1024

This is just an educated guess, but I am pretty sure this is what happens:

Using the jpeg_stdio_src() or jpeg_stdio_dest() functions requires that the
calling code and libjpeg use the same C library. Recall that on Windows, there
are several C libraries: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll,
crtdll.dll, and various static libraries.

File descriptors (the small integers returned by open() and stored inside the
FILE struct) are in reality an index into a table local to the C library. A
file descriptor returned from one C library has no meaning (or a completely
different meaning) in another C library.

The libjpeg library distributed by gnuwin32 is built against the msvcrt.dll
C library, because that is the one that mingw (the compiler gnuwin32 uses)
targets
by default, and that C library is part of the Windows operating system and
present
on all Windows machines. The other libraries come with the Microsoft compilers
(but are redistributable as far as I know).

Visual Studio 2003 is as far as I know not even capable of producing code that
would use msvcrt.dll (At least not without some severe undocumented and
unsupported
hacking.) It produces code that uses either msvcr70.dll (or msvcr71.dll?), or
its static C library.

Thus, when the code you compiled in example.c calls fopen(), the returned FILE
struct contains a file descriptor that has meaning only to the same C library
that your code uses.

Passing the FILE pointer to libjpeg won't work. When libjpeg then uses
msvcrt.dll
to read from the file, it will fail because the file descriptor you passed to
it has no meaning (or happens to refer to some completely different file opened
by that C library).

You should complain to Microsoft for selling you a compiler that isn't capable
of producing code that uses the C library they bundle with the operating system.
Ask for your money back, and switch to using the GNU compiler.

Or, recompile the libjpeg library to use the same C library as your other code
does. If you build a DLL, make absolutely sure to use a different name for the
DLL, though, than what gnuwin32 uses.

Or, don't use the jpeg_stdio_src() and jpeg_stdio_dest() APIs, but other ways
to feed data into libjeg. There are several.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=74807

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV