openjp2 debug works, release build does not

[GoogleCodeExporter]

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

Original issue reported on code.google.com by anon_m...@me.com on 2 Apr 2013 at 2:02

• Blocked on: #120, #198
• Merged into: #198

[GoogleCodeExporter]

You should use the '_v3()' functions:

void opj_stream_create_default_file_stream_v3 (const char *fname, 
   OPJ_BOOL p_is_read_stream);

void opj_stream_destroy_v3(opj_stream_t* p_stream);

opj_stream_t* opj_stream_create_file_stream_v3 (const char *fname,
   OPJ_SIZE_T p_buffer_size, OPJ_BOOL p_is_read_stream);

winfried

Original comment by szukw...@arcor.de on 2 Apr 2013 at 10:51

[GoogleCodeExporter]

To correct the problem you need to use the trunk version. However be carreful 
the trunk version is unstable now. You should wait a little more.

Mickael

Original comment by savmick...@gmail.com on 10 Apr 2013 at 9:28

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 24 Feb 2014 at 9:04

• Now blocked on: #120

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 24 Feb 2014 at 9:04

• Now blocked on: #198

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 24 Feb 2014 at 9:11

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Feb 2014 at 4:25

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 27 Feb 2014 at 5:11

• Changed state: Duplicate