NewDTObject with JPEG datatype crash

[betajaen]

Hello,

I having a strange issue with NewDTObject and the DTA_Handle tag item. When I do so, I get a #80000008 Guru when I do so.

I would like to read a JPEG image within a file, but its not at the beginning.

I am 100% certain where it seeks to is a valid JPEG header, and the BPTR is correct and seeked to the correct position.

I have checked this file and location with a hex editor. I have also extracted the JPEG file via a hex editor and it loads fine. Loading another similar JPEG file via the name as a path works fine as well.

This is my code (simplified):

BPTR file = Open("some-file", MODE_OLDFILE);

Seek(file, offset, OFFSET_BEGINNING);

Object* dtObj = NewDTObject(
	NULL,
	DTA_SourceType, DTST_FILE,
	DTA_GroupID, GID_PICTURE,
	PDTA_Remap, TRUE,
	PDTA_Screen, (ULONG) mScreen,
	PDTA_DestMode, PMODE_V43,
	DTA_Handle, (ULONG) file,           // << -------- This here.
	TAG_DONE
);

I know, there is a way to load in files through memory, but I don't want the Amiga to temporarily allocate 80kb each time I wish to load an image.

I am on AmigaOS 3.2.1, with the default JPEG data type.

If anyone can shed a light on this, It would be most appreciative.

Thankyou,

betajaen

[phx]

You should provide a compilable source to make it easier for people to help you. I spent quite some time now to construct a test from the information you provided, and I never worked with datatypes in AmigaOS before. It looks like this:

#include <exec/libraries.h>
#include <dos/dos.h>
#include <intuition/intuition.h>
#include <datatypes/pictureclass.h>
#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/intuition.h>
#include <proto/datatypes.h>

struct Library *DataTypesBase;
struct IntuitionBase *IntuitionBase;
#define DTVERSION 43

int main(int argc,char *argv[])
{
  BPTR file;
  struct Screen *myscr;

  IntuitionBase = (struct IntuitionBase *)
                  OpenLibrary("intuition.library", 37);
  if (IntuitionBase == NULL)
    return 20;

  if (DataTypesBase = OpenLibrary("datatypes.library", DTVERSION)) {
    if (argc>1 && (file = Open(argv[1],MODE_OLDFILE))) {
      if (myscr = OpenScreenTags(NULL,
                                 SA_Title, (ULONG)"Test",
                                 TAG_DONE)) {
        Object *dtobj = NewDTObject(NULL,
                                    DTA_SourceType, DTST_FILE,
                                    DTA_GroupID, GID_PICTURE,
                                    PDTA_Remap, TRUE,
                                    PDTA_Screen, (ULONG)myscr,
                                    PDTA_DestMode, PMODE_V43,
                                    DTA_Handle, (ULONG)file,
                                    TAG_DONE);
        Delay(50);

        if (dtobj) {
          Printf("dtobj = %08lx\n",(ULONG)dtobj);
          DisposeDTObject(dtobj);
        }
        else
          Printf("NewDTObject failed.\n");

        CloseScreen(myscr);
      }
      Close(file);
    }
    else
      Printf("Cannot open file!\n");

    CloseLibrary(DataTypesBase);
  }
  else {
    Printf("No datatypes V%ld!\n",DTVERSION);
    CloseLibrary((struct Library *)IntuitionBase);
    return 10;
  }

  CloseLibrary((struct Library *)IntuitionBase);
  return 0;
}

I can confirm that it freezes my A3000 with OS3.9 and standard datatypes, after opening the screen. No matter what type of file I provide.

[betajaen]

Hi Phx,

Thankyou for replying. Very sorry for not producing an example. I will do better next time.

Anyway. I doubt this is a bug with datatypes.library; AmigaOS 3.2.1 and 3.9 are from different times.

My only conclusion is that DTA_Handle cannot like used by that. Maybe its used to get the Handle (BPTR) of the datatype. Although the documentation suggests it can be used in the NewDTObject function, as an alternative to the name argument.

For now; I have temporarily extracted the data from the original file, and wrote it to the RAM drive, and then open it that way - which works, but not ideal.

I did experiment with the DTA_SourceType being DTST_MEMORY, and load in the data manually into RAM, but that did not work either (although no crash, just a NULL Object), may I did that one wrong though.

Thankyou,

betajaen

[phx]

Originally Posted by betajaen

My only conclusion is that DTA_Handle cannot like used by that. Maybe its used to get the Handle (BPTR) of the datatype. Although the documentation suggests it can be used in the NewDTObject function, as an alternative to the name argument.

Which documentation did you read? I checked the datatypes.doc from the NDK3.2 and it states, under datatypes.library/NewDTAObjectA:

        DTA_Handle - Can optionally be used instead of the name field.
            Must be a valid file lock if DTA_SourceType is DTST_FILE.
            Must be a valid IFFHandle if DTA_SourceType is DTST_CLIPBOARD.
            Will be ignored if DTA_SourceType is DTST_MEMORY.

            NOTE: If you provide a file lock if DTA_SourceType is DTST_FILE
                  then this file lock will become associated with the
                  data type object. Do not UnLock() it, or freeing the
                  data type object will result in the same lock being
                  unlocked again!

                  If you provide a file lock on a file, you must also
                  provide the name of the file or it will fail to open.
                  This makes the use of the DTA_Handle difficult to
                  justify for this use case.

Which means you have to

Lock()

that file, not

Open()

it. Also don't

UnLock()

, because

DisposeDTObject()

does that for you. And you still have to specify the correct file name in the first argument!

Worked for me. No more crash. Although I'm not sure how useful this feature is.

[betajaen]

That's the documentation I was following. I must of confused DTST_File with a BPTR from Open, rather than from a Lock.

So it seems its not possible for it to directly load a file within the middle of another file after all. That is disappointing.

Thankyou for your help!

[thomas]

Originally Posted by phx

And you still have to specify the correct file name in the first argument!

This is self fooling. The same "error" is also in the DTST_RAM example in the OS 3.9 NDK. DTST_RAM does not work in OS 3.9. The example works because it specifies the file name of the original file. The memory area given is ignored, instead the datatypes sub class opens and reads the named file.

I guess the same is true for DTST_FILE with DTA_Handle.

Furthermore all documentation is worth nothing if the datatypes sub class does not support it. Reading data is not done in a central place but in the sub class code. You cannot trust every sub class author to implement all methods to read data. So if your code is public you should consider that the user can have installed replacement datatypes which do not support the less famous variations.

Finally reading part of a file which is not in the beginning of the file is a very special case of another special case. I would expect that to work only by chance if at all.

[betajaen]

Hi Thomas,

Thankyou for filling the gaps.

You right being this special case, but I am trying to read in files within an uncompressed archive. Essentially, 1000s of JPEGs in a custom file format (with other application specific information). I hoped not to extract them into separate files, but this looks likely to be the case now.

Thankyou both for your help and insight.

[thomas]

If you know that the file format is always JPEG you could use jpeg.library instead of datatypes. IIRC jpeg.library has callback hooks for reading data, so you could get the data from wherever it is.