Re: NewDTObjectA() extended error issue [Bug Reports]

Forum Index

Board index » Development » Bug Reports » NewDTObjectA() extended error issue

Browsing this Thread: 1 Anonymous Users

Bottom

Previous Topic

Next Topic Register To Post

magorium

Re: NewDTObjectA() extended error issue

Home away from home

Thank you for the confirmation ncafferkey.

I've reported it to the ML.

Yes indeed, the previous question is now moot (unless it solves current problem

)

Posted on: 2015/11/12 17:39

ncafferkey

Re: NewDTObjectA() extended error issue

Home away from home

I get the same error while using the AROS-20151111-linux-i386-system and AROS-20151111-pc-i386-contrib packages together. Could you report this on the dev list please?

I'm assuming your previous question is moot now that the contrib package is up-to-date.

Posted on: 2015/11/12 13:03

magorium

Re: NewDTObjectA() extended error issue

Home away from home

Unable to test, v1 mingw nightly 11/11

sh
gcc testDT.c -o testDT
/Development/lib/gcc/i386-aros/4.6.4/libgcc.a: file not recognized: File format not recognized

Help ?

Posted on: 2015/11/11 20:37

magorium

Re: NewDTObjectA() extended error issue

Home away from home

Well, at least now, when i do:
testDT testDT

i receive the following output:
Quote:

load file testDT as datatype
lasterr = 212
object is not of required type

Which would indicate that your fix improved the previous encountered situation

BTW: i tested only on 68k for now (not hosted v1).
If i install aros hosted v1 nightly and overwrite development with that from boot-iso from 07/11 (last available build) should that work when compiled natively ?

Posted on: 2015/11/11 1:50

magorium

Re: NewDTObjectA() extended error issue

Home away from home

Thank you very much for having taken a look and attempt to improve things ncafferkey.

It isn't a shop-stopper perse, as the return-value does tell me that the loaded file doesn't return a valid object, so error checking can be done.

It was in light of the workbench backdrop load failures, that i wanted to make a small helpful utility that would show exactly why that (sometimes) fails, expressing the exact reason to user/tester.

Having a 'fix' for V1 would be good enough, as that is where things seems to go wrong atm.

I'll try to check things out after new nightly has build.

Thanks again, appreciated.

Posted on: 2015/11/9 19:36

ncafferkey

Re: NewDTObjectA() extended error issue

Home away from home

I think you're right. The handling of IoErr()/SetIoErr() is sloppy in that function. I've committed a fix for ABIv1 in SVN r51208. However, I haven't tested that the right error condition is definitely passed through in your situation, and there may be other places where it was assumed that IoErr() would still contain a meaningful error that I'm not aware of.

EDIT: can you work around the bug in ABIv0 for now, or is it a show stopper?

Posted on: 2015/11/9 19:18

magorium

NewDTObjectA() extended error issue

Home away from home

Why does following code not return an error number for IoErr() when loading unsupported file-type ?


int main (void)

{

  struct RDArgs *rdargs;

  static struct { char *filename; } args = {NULL};

  Object *o;

  SIPTR lasterr;



  if ( rdargs = ReadArgs ((CONST_STRPTR)"FILE/A",(APTR)&args,NULL) )

  {

    printf("load file %s as datatypen", args.filename);

    if ( o = NewDTObject ( args.filename,DTA_GroupID,GID_PICTURE,TAG_END ) )

    {

      printf ("datatype was created successfullyn");

      DisposeDTObject (o);

    } 

  }



  lasterr = IoErr();

  printf ( "lasterr = %ldn",lasterr );

  PrintFault (lasterr, NULL);



  return 0;

}

because, according to reference:
Quote:

Result
A BOOPSI object. This may be used in different contexts such as a gadget or image. NULL indicates failure -- in that case IoErr() gives more information:

ERROR_REQUIRED_ARG_MISSING -- A required attribute wasn't specified.

ERROR_BAD_NUMBER -- The group ID specified was invalid.

ERROR_OBJECT_WRONG_TYPE -- Object data type doesn't match DTA_GroupID.

Looking at the AROS sources for both v1 and latest V0 trunk from deadwood, i am able to locate the code that should apply to my situation, and shows that indeed it does a SetIoErr(ERROR_OBJECT_WRONG_TYPE).

Maybe i'm dense in my analysis, but the code seems to continue after that.

Since i've not suplied a DTA_DataType attribute it will skip that part. Also the BaseName seems not set, so that part would also be skipped.

But then the code does this check: if(dtobj == NULL) which would apply.

Looking at the code that gets performed when that if-statement is true i can see all kind of operations that could mess with IoErr() value, such as UnLock() and CloseIFF(). (i haven't pursued called routines tough).

Help ?

Posted on: 2015/11/7 5:31