Re: [MiNT] AES-calls without appl_init

[m0n0 <ole@monochrom.net>]

Am Freitag, den 24.02.2012, 10:59 +0100 schrieb "Helmut Karlowski" 
<helmut.karlowski@ish.de>:

> Sure - that's why I tried to get marathon to work (should do now 
> btw).
> At first I ran it from ext2, and had to rename/copy some files to get 
> it
> starting. I must have done something wrong, which caused it to 
> produce
> the memory-violation. But I tried to stabilize the system to keep it 
> up.
> Really strange things happened, apparently code has been overwritten.

I know of one severe bug. I don't know anything about the PureC builds. 
So everything
I'm saying is just about the coldfire build produced with Coldfire.

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.

On the firebee build, this works for at least 2 calls. After that, an 
Call to Fread() crashes, it's reproducable.
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() ...

After the image was loaded, it probably does some further processing 
afterwards, memcpy() etc... It could be that
there is something wicked happening, which affects the later calls to 
load_images().

There is no problem when disabling icon cache!

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 )

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

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

Greets,
m