Probleme mit libjpeg-turbo unter 64bit

[Cypheros]

Hi,

ich beiße mir hier gerade seit Stunden die Zähne aus an libjpeg-turbo. Ich kriege die 64bit-Version nicht an laufen. Verschiedene DLLs habe ich schon probiert aber immer die allseits beliebte "c0000005 ACCESS_VIOLATION". In der 32bit-Version funktioniert es komischerweise.

Zum Testen habe ich mir aus dem Google-Archiv "Delphi-libjpeg-turbo" heruntergeladen und nach den ersten Fehlversuchen die libJPEG.pas mit der von Eric Grange ersetzt, die aktueller zu sein scheint.

Den Versuchsaufbau habe ich mal als Zip zusammengepackt. Ich vermute, dass es am Speichermanagement liegen könnte. Die DLL wird initialisiert und auch jpeg_create_decompress akzeptiert noch den jpeg_decompress_struct record.

In der Routine LoadFromStream in cgJpeg.pas kracht es an dieser Stelle:

Code:

  // read header of jpeg
  jpeg_read_header(@jpeg, False);

Vielleicht hat hier jemand ja eine Idee, wo das Problem sein könnte.


Vielen Dank im Voraus,
Frank

P.S.: Delphi 11.1 unter Windows 11.

[Raible]

da habe ich mir auch schon mal einen Wolf gesucht.
Prüfe folgende Datenstrukturen

Code:

jpeg_destination_mgr = record
    ...
  free_in_buffer: NativeInt;  //hier muss NativeInt statt Longint stehen 
    ...
end;
  
jpeg_source_mgr = record
     ...
    bytes_in_buffer: NativeInt;  //hier muss NativeInt statt Longint stehen
    ...
  end;

sonst werden bei einer Zuweisung nur die unteren 32 Bits gesetzt. Die Oberen sind dann zufällig belegt.

[Cypheros]

Danke, darauf wäre ich nie gekommen. :thumb:

Erst nachdem ich mir die jpeglib.h nochmal genau angeschaut habe, sah ich deinen Hinweis bestätigt, dass free_in_buffer und bytes_in_buffer vom Typ size_t sind, was NativeUInt in der Delphi-Welt bedeutet. (um ganz präzise zu sein) :wink:

Code:

struct jpeg_destination_mgr {
  JOCTET *next_output_byte;     /* => next byte to write in buffer */
  size_t free_in_buffer;        /* # of byte spaces remaining in buffer */

  void (*init_destination) (j_compress_ptr cinfo);
  boolean (*empty_output_buffer) (j_compress_ptr cinfo);
  void (*term_destination) (j_compress_ptr cinfo);
};


/* Data source object for decompression */

struct jpeg_source_mgr {
  const JOCTET *next_input_byte; /* => next byte to read from buffer */
  size_t bytes_in_buffer;       /* # of bytes remaining in buffer */

  void (*init_source) (j_decompress_ptr cinfo);
  boolean (*fill_input_buffer) (j_decompress_ptr cinfo);
  void (*skip_input_data) (j_decompress_ptr cinfo, long num_bytes);
  boolean (*resync_to_restart) (j_decompress_ptr cinfo, int desired);
  void (*term_source) (j_decompress_ptr cinfo);
};

Folgende beiden Zeilen müssen dann aber auch korrigiert werden, damit es perfekt ist:

Code:

  jpeg_CreateCompress: procedure(cinfo: j_compress_ptr; version: integer; structsize: NativeUInt); cdecl;
  jpeg_CreateDecompress: procedure(cinfo: j_decompress_ptr; version: integer; structsize: NativeUInt); cdecl;

Danke,
Cypheros

[Raible]

evtl. muss auch noch

Delphi-Quellcode:

  
  jpeg_source_mgr = record
    ...
    skip_input_data   : procedure (cinfo : j_decompress_ptr; num_bytes : NativeUInt); Cdecl;
    ...
  end;

angepasst werden.
Und was ist eigentlich mit

Delphi-Quellcode:

  jpeg_memory_mgr = record
    { Method pointers }
    ...
    max_memory_to_use   : Longint;

    { Maximum allocation request accepted by alloc_large. }
    max_alloc_chunk     : Longint;
  end;

bei mir funktioniert das seit einigen Jahren im produktiven Einsatz.
Wahrscheinlich wurden die entsprechenden Strukturen nur nicht verwendet.

[Cypheros]

Nein, ein Blick in die jpeglib.h zeigt: num_bytes ist long (LongInt)

Code:

  void (*skip_input_data) (j_decompress_ptr cinfo, long num_bytes);

und max_memory_to_use und max_alloc_chunk ebenfalls.

Code:

  long max_memory_to_use;

  /* Maximum allocation request accepted by alloc_large. */
  long max_alloc_chunk;

Wie gesagt, tauchen die Probleme nur in der 64 Bit Version auf. 32 Bit ist ok, da machen sich die fehlerhaften Deklarationen auch nicht bemerkbar.

Ich hatte schon befürchtet, dass meine Crosscompiler-Toolchain nicht mehr vernünftig funktioniert, da ich Anfang des Jahres meinen Entwicklungs-Rechner auf Windows 11 migriert habe und mir dann alles neu einrichten musste.