Skip to content

openjp2 debug works, release build does not #217

Closed
@gcode-importer

Description

Originally reported on Google Code with ID 217

Prefix this with I am not a great programmer, so I may be off in left field here....

System setup
Windows 7 x64 Professional
Compiling a 32bit application (console) using Visual Studio 2010.

Having an issue with openjp2.dll and looking for some guidance.  

Downloaded the binary release for win32, created a hello world compression application
and could not get past the call to:
opj_stream_create_default_file_stream()

Would get an access violation every time.  

I downloaded the source, build it (cmake is pretty neat btw), and got the opj_compress
sample to build and run. Figured I was doing something wrong with the API, so I hacked
up the opj_compress code until it matched my hello world compression program, and it
worked!

Copied this code verbatim over to my hello world application project, but still had
access violation errors on the opj_stream_create_default_file_stream() function, again
figured that I was doing something wrong with my compiler/linker settings, so I spent
a while making sure that all of my project settings matched the opj_compression example,
all failed miserably.  However, when I linked to the library in the openJPEG source
area that I had built...magic!  

Rebuilt the openjp2 library in release mode and re-linked to my application...blamo!


Great, seen this behavior before debug works and release doesn't...ususally something
is destroying your stack..

Recompiled the openjp2 library in RelwithDbg, stepped through the code and the issue
seems to be in the function (line 210 openjpeg.c):


static OPJ_UINT64 opj_get_data_length_from_file (FILE * p_file)
{
    OPJ_OFF_T file_length = 0;

    OPJ_FSEEK(p_file, 0, SEEK_END);
    file_length = (OPJ_UINT64)OPJ_FTELL(p_file);
    OPJ_FSEEK(p_file, 0, SEEK_SET);

    return file_length;
}

When OPJ_FSEEK is called the value of file_length is 6568605759971893492, oh o....something
has clearly gone wrong....

When I re-run using the Debug version of the library file_length is good to go....

Looking at the open issues, #120 and #198 suggest that passing a FILE* to the CRT is
a bad idea (read the Microsoft article and I'm going to digest).

I am compiling both the library and the application with /MD (and /MDd respectively)
so I am not sure that this is what I am fighting with....feels much more like a stack
issue.

There is even a comment in #120 with some better functions to use.  Can anyone expand
on how to use those functions instead of the opj_get_data_length_from_file() API call?


Been trying for a while and have not been able to get my program to go with those calls.
 How should I use them?  Thanks much!

~joe

Reported by anon_mail@me.com on 2013-04-02 14:02:54

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions