Re: [MiNT] AES-calls without appl_init

["Helmut Karlowski" <helmut.karlowski@ish.de>]

m0n0 wrote:

>  All the Draconis tools I currently got into are having an function
>  called load_images.
>  This function loads images icons etc.
>  It's called several times with different image file as parameter.
>  If the image cache is enabled, it will look for an cached image file,
>  read it and just return the content.
>  Otherwise, if icon cache is enabled and the cache is not populated, it
>  will read the original image,
>  convert it to screen format, do some dithering etc. and save it as
>  cache file.

That's what I thought would cause the memory-violation, because I just
renamed some files, that were likely the wrong ones. This also caused the wrong display.

>From VFAT it works ok.

>  On the firebee build, this works for at least 2 calls. After that, an
>  Call to Fread() crashes, it's reproducable.

Buffer too small.

>  The funny thing is: using fread seems to work fine. However, fread in
>  AHCCCF is mostly an wrapper to Fread - except when the device flag is
>  set onto that file. then it will to fgetc() ...

fread should always use the FILE-structure.

>  I either assume an bug in the Firebee OS, an Bug withing AHCCCF, or and
>  bug within the image data processing routines
>  somewhere ( could be in Draconis, XaAES, or fVDI )

Choose one :-)


>  Helmut, the problems you were seeing - did they have something to do
>  with images / images cache?

Pretty sure!

>
>  The icon cache creates large files ( I believe on true color systems
>  likely to be > 200k ) -
>  all this memory is malloced by one single call. Maybe that's not so
>  fine for some compilers?

Should rather be the malloc from the lib it uses.

>  With NetSurf it can happen that I malloc(1MB), - but that's not an
>  problem for the OS or GCC. Works fine.

Would be bad if not ..


-Helmut