In neverball log:

indeces 43949,51966 -> 0xABADCAFE

@kas1e

You have got pointers in this index array!



26935 == hex 0x6937
36424 == hex 0x8e48

-> 0x69378e48

kinda close to pointer passed to glDrawElements(), isn't it?

@kas1e

In src/gl/list.c I noticed that it uses dynamic sized arrays on the stack in a few places (maybe elsewhere too).

GLushort ind_line[ilen*4+2]

Maybe there's something wrong with that. I don't know how big this array (or ilen) can get. Maybe try even bigger stack size (like 20 MBytes).

Or try changing such things in corresponding { ... } block with

{
GLUshort *ind_line = malloc((ilen*4+2) * sizeof(GLushort));

[...]

free(ind_line);
}

Or think about things like reading lower 16 bit from a 32 bit variable like this:

ULONG var = 0x12345678;
ULONG *ptr1 = &var;
UWORD *ptr2 = (UWORD *)&var;

UWORD w16 = (UWORD)*ptr1; /* works: -> 0x5678 */
UWORD w16 = *ptr2; /* works too on little endian: -> 0x5678 */

Maybe some endianess problem. Has gl4es ever been tested on Linux PowerPC?

Endianess problems sometimes appear in unexpected places. in AmigaOS/Exec/MakeLibrary() for example there's the table of functions which can contain function pointers (4 byte entries) or, if the first WORD in the table == 0xFFFF, then instead it contains offsets (2 byte entries). The check "if (*WORD*)funcInit==-1)" does not work on little endian (AROS), which was discovered more or less by "luck" when by pure coincidence the first function pointer happened to end exactly at address 0x????FFFF. And so the *(WORD *) saw 0xFFFF there and assumed it was offsets instead of absolute addresses (a function on x86 may start at an odd address).

@kas1e

Quote:

Testing with SDL_FreeSurface() commented out would not be about problem in Cadog code but would be a workaround for theoretical problem in outside driver/gl/wrapper/whatever code in theoretical scenario like this:

- the SDL surface pixels happen to be in VRAM when cadog locks the surface and calls TexImage2D

- the driver/gl/warp3d whatever happens to have accelerated function to move direct pixel (no bitmap handle) data from one place in VRAM to other place in VRAM, maybe similiar code as used for function like WritePixelArray() where source is just raw pixel pointer.

- in driver/gl/warp3d the TexImage2D implementation uses some movetoVRAM() function which mistakenly looks at source address which happens to be in VRAM and mistakenly decides to use the accelerated but asynchronous helper function instead of normal CPU based CPU to VRAM transfer.

- the source texture data passed to TexImage2D() is reused too early by other things, because there's nothing which waits for async transfer of data to texture to complete.

@kas1e

It may also be the code execution speed which changes by adding/changing code (especially with slow debug output over serial), so instead of printf, dprintf try adding a delay with a simple for(;;) loop which does nothing:

/* global variable! */
int delaycount = 10000000;
int delaycounter;

#define DELAY for(delaycounter = 0; delaycounter < delaycount; delaycounter++);

/* elsewhere */

[...]

DELAY

[...]

This way you can try to reproduce problems/make them go away again , by testing various values of delaycount. And the code is always the same, so no chance of shifting things around in memory. Only things changing is contents of delaycount variable.

In case it is delay related, not place in memory related.

@kas1e

dprintf: do you have it set up to show up in console window (sashimi)? What if you make it go into file or NIL:?

@kas1e

I looked a bit around in cadog source. What happens if in sdlgl.c you comment out all calls to SDL_FreeSurface().

I don't really know GL, but what I see in there is code like this:

if (SDL_MUSTLOCK(img)) SDL_LockSurface(img)
glTexImage2D(img->pixels);
if (SDL_MUSTLOCK(img) SDL_UnlockSurface(img);

And my thinking is this: if glTexImage2D() is hw accelerated/asynchronous (no idea if it is), then after unlocking, the glTexImage2D() could still be in progress when the img == BitMap() is being killed/freed from memory. So img->pixels is valid when glTextImage2D() starts, but it may not be valid until it completes.

@kas1e

Quote:

Apart from mem trashes it could be things like compiler generating wrong code. Where sometimes it may not be even 100 % compiler fault, like with this strict aliasing stuff where it could be more a fault in the sources. Ever tried compiling with -O0 and or things like -fno-strict-aliasing? Maybe have once a gain a look at disassembled function which calls aglCreateContextTags() (the real function, not the dummy one, because it can be that correct code is generated for dummy one, but not real one which does more things incl. dprintf etc.).

Or it could be inside OGLES2's aglCreateContextTags() which must ~extract/~cast/~convert the "..." correctly to a struct TagItem* before passing it on to aglCreateContext(). On the various OSes/cpus and versions of it and it's compilers there are different methods (&lastparam +1, va_start() + co., va_startlinear() + co.,)

@kas1e

That asm is really hard to read for me. Do I see this correctly that tags are #defined (I don't have headers)
to



Normally tags need to be >= TAG_USER (0x80000000 + something). Does OGLES2 parse tags manually. Because otherwise there is conflict, because TAG_IGNORE = 3, and TAG_SKIP = 1, so such a taglist would be broken when used with normal tag parsing functions like NextTagItem().

I noticed



Does other OGLES test programs/demos/games/whatever work if they do this too and they are at the same time using vararg functions like aglCreateContextTags(). Because when USE_INLINE is active the IOGLES2->aglCreateContextTags() probably never gets called as the inlines likely map it to IOGLES2->aglCreateContext().

So it could be that IOGLES2->aglCreateContextTags() itself is broken inside IOGLES2.

@kas1e

I would not rule out other kind of error (= not necessarily memory trash). Maybe the vararg function call simply goes wrong, like some header trouble causing VARARGS68K being defined to nothing and then the aglCreateContextTags() goes wrong, ie. it no longer pushes all args on the stack, instead some in registers, some on stack, like in a normal (non VARARGS68K) vararg call.

Look at generated compiler output (gcc -S). Add some dummy function which does the call and nothing else. So it's easier to read the asm (PPC asm is bad enough to read already):

@kas1e

Check this context array creation/finding/expanding/shrinking routines in agl.c. This in agl_context_remove() looks suspicious:



If an array contains len items then accessing array[len] is invalid. Even here where array is allocated/reallocated in chunks of multiple of 10 (agl_context_cap) and zeroed. Especially in case len happens to be multiple of 10, because then array[len] points to unallocated memory/chunk (not zeroed).

@kas1e

Try

@kas1e

So since you seem to both have the non-vararg functions:

aglCreateContext()
OGLES2->aglCreateContext()

what your vararg wrapper function aglCreateContextTags(...) needs to do is to call one of those two (shouldn't matter which)) making sure to ~convert/~cast the "..." to a struct TagItem * in the correct way.

Either in same way as it is done elsewhere for similar wrappers (look in OS headers? VARARG68k, va_startlinear,whatever) or manually in similar way as GetTagsFromStack() in AROS source (compiler/alib/alib_util.c) which parses and clones the tags in va_list to new allocated memory.

@kas1e

You cannot have a vararg wrapper function calling a vararg wrapped function (passing varargs from one to the other). That's not possible.

A wrapper function with vararg params only works if the wrapped function does *not* have vararg parms, ie. there is an alternative version of the wrapped function which instead of ..., takes for example a "va_list" param. Or a "struct TagItem *" param.

It may look like it sort of works (but things like adding variables, adding dprintfs() changes behaviour) but it really doesn't work. It just looks like that because the vararg params that were passed to wrapperfunction() are still there on the stack (and on PPC maybe partly in registers), so the wrapped function may pick them up, but incorrectly/half wrong/half right/completely wrong/not at all.

Try playing with this test program (try also on 68k, x86 if possible):



OTOH you could make wrapper using macro: #define wrapperfunction(a, args...). That would work.

@salass00

Quote:

The last blit after the while loop may have a 0 blit height.

@Chris

Exec IO requests are tricky. If you have have received back a request and GetMsg()ed it, do not do the CheckIO/AbortIO/WaitIO stuff, otherwise the WaitIO could Remove() the request a second time (it was already removed by GetMsg() call).

Set some req->timer_pending flag to TRUE when calling SendIO(), set it back to FALSE when GetMsg()ing, and do the CheckIO/AbortIO/WaitIO only if timer_pending is TRUE.

bugs: maybe not the case here, but handling events like this:



it's easy to run into problem that for example HandleEvent when reacting on IDCMP_CLOSEWINDOW kills the window and when HandleEvent() returns window is no longer valid and the ReplyMsg() will do bad things.

@Fairdinkem

Quote:

except "soon" ...