0

I copied this code from the libjpeg example and im passing it standard files;

FILE *soureFile;
if ((soureFile = fopen(sourceFilename, "rb")) == NULL)
{
    fprintf(stderr, "can't open %s\n", sourceFilename);
    exit(1);
}

jpeg_stdio_src(&jpegDecompress, soureFile);
jpeg_read_header(&jpegDecompress, true);

It results in a file pointer that contains no information and therefore breaks on the last line with access violations. Any ideas?

EDIT: On Tobias' advice the fopen does appear to open the file ok but the jpeg_read_header is in turn failing with the access violation still.

EDIT: After a little more digging
JPEG support with ijg - getting access violation

Community
  • 1
  • 1
Adam Naylor
  • 6,172
  • 10
  • 49
  • 69
  • 1
    Are you sure that the rest of the code isn't at fault, and that the file contains what you think it does? – Ori Pessach Jun 02 '09 at 12:22
  • I am still not clear. Is fopen() the above code returning NULL or not? –  Jun 02 '09 at 12:23
  • if sourceFile != NULL, then fopen succeded. Could you try to read from sourceFile to rule the fopen-part out (for example using fgetc). – Tobias Langner Jun 02 '09 at 12:23
  • @Neil: fopen returns a file *, whose properties are 's. Does this make sense? – Adam Naylor Jun 02 '09 at 12:25
  • @Tobias: i'll try that and eliminate the fopen. – Adam Naylor Jun 02 '09 at 12:26
  • @Adam a FILE * is an opague pointer - you are not supposed to do anything with it except use it with the various stream APIs. You certainly can't extract useful inforrmation from it. –  Jun 02 '09 at 12:30
  • @Adam: Can you tell whether jpeg_stdio_src() call succeeds? Also whether you are reading the file inside it? – Naveen Jun 02 '09 at 12:30
  • how is jpedDecompress declared and allocated? I guess you have a memory violation with the jpegDecompress-Pointer being written at. – Tobias Langner Jun 02 '09 at 12:31
  • 2
    The programmer is not really supposed to make use of the individual fields of a FILE struct. The fact that it contains bad pointers does not necessarily mean that the structure is corrupted, but rather that those fields are not meant to be used - or used as pointers - at the time you read it. – Raphaël Saint-Pierre Jun 02 '09 at 12:32
  • @Naveen: It appears as though it is successful, there is no return code, and the built in error mechanism (for libjpeg) is reporting no error. @RaphaelSP: thanks for clearing that up. – Adam Naylor Jun 02 '09 at 12:37
  • @Tobias: it is declared as an automatic variable, as per the example. And then initialised via jpeg_create_decompress – Adam Naylor Jun 02 '09 at 12:40
  • 1
    what compiler is used for the dll and for your code? Perhaps using the same compiler solves your problem with the FILE-pointer being transferred to the dll. – Tobias Langner Jun 02 '09 at 13:31

2 Answers2

2

Use strerror or perror to get exact reason:

FILE *soureFile;
if ((soureFile = fopen(sourceFilename, "rb")) == NULL)
{
    perror("fopen failed");
    exit(1);
}
Artyom
  • 31,019
  • 21
  • 127
  • 215
  • Didn't know about those thanks. However due to the valid pointer being return from fopen, this line will never be hit. – Adam Naylor Jun 02 '09 at 12:21
  • 1
    So in fact fopen() is working and the problem is with your jpeg code! –  Jun 02 '09 at 12:26
  • I think what Adam means is that the pointer `fopen` returns is valid and points to a valid `struct` but the data in the `struct` is invalid. I just ran into this problem and hence this question. To further clarify, the debugger can access the variables in the returned value: `_ptr`, `_base` and `_tmpfname` are all invalid pointers. What we are told when looking at `fopen`'s documentation is that if the file fails to open, `NULL` will be returned. This is not the case here. – Samaursa Oct 30 '13 at 15:22
1

"select isn't broken".

If fopen returned a valid file pointer, and jpeg_read_header can't use it, someone between those two statements has done something bad to it.

The only one in between is the jpg_stdio_src call, which wouldn't fail if all it's preconditions are fulfilled.

Bottom line: see why jpg_stdio_src fails. My guess: it needs to be constructed using the jpeg_create_decompress macro.

xtofl
  • 40,723
  • 12
  • 105
  • 192