As said IMO it's very likely problem of some uninitialized variable in this shader compiling stuff. Maybe somewhat hidden (compiler may not warn about it) if for exampled caused as side effect of unimplemented/unhandled functionality/attributes/whatever.

The thing with the call of the magic functions (printf(), Delay(1)) that make things work, is, that the calling of this functions will cause modification of things on the stack so they will influence how uninitialized variables look like when they end up being used in other code (shader compilation) which is exectuted after that = ~"in the future".

Funny experiment: If

Delay(1);

works, but Delay(0) doesn't it probably is possible to make the working thing not-work again by calling both:

Delay(1);
Delay(0);

My guess now is that it's most likely some unimplemented functionality which causes some uninitialized variable to stay uninitialized and therefore causing random behaviour (which can be influenced by adding removing "magic" calls)

Like maybe in SDL_shaders_gl.c:

GLint status;

...

ctx->glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);

If this GL_OBJECT_COMPILE_STATUS_ARB param/flag/whatever is not implemented in the GL libraries or whereever ...

IIRC in AROS I once had a funny situation in a some test program which opened a window and would quit when you press some key. In the shell you typed in the command, pressed RETURN key, the window opened quickly and the RETURN key release happened after that and so the event went to the window/test program which then quit immediately.

Btw, what does "not work" mean? Does it crash? Does it quit?

To me this does not look or "smell" like race condition or timing related at all. Add an always failing runtime checked (to make sure it can't be optimized away) check around printf call that usually makes the thing work and see what happens. If it still works even if the actual printf() call never gets executed then you know it's not timing/race condition problem.

- printf("blablabla")
+ if ((int)SysBase == 0x1234) printf("blablabla");

Quote:

If the function never gets called it may be optimized away.

Quote:

The compiler may have optimized printf() into a putchar().

It may also just be that your magic function (Delay() or printf()) triggers some linker autoinit stuff which is otherwise not happening.

What happens if you put the Delay() or printf() in some place in the .c file which never gets called. Or inside some check which never is true (but make sure it's not something the compiler optimizes away completely). Like "if (SysBase->SysFlags == 0xABCD)"

@kas1e

That loading screen does not really look messed up, but the areas where there is text have the background behind darkened which would happen in cases like where someone had had a 32 bit truecolor screen, read the pixels into a 16 bit truecolor buffer and write it back to 32 bit screen.

The asm source you linked contains lots of data (dc.l, dw.c) which is code. For example LAB_0323 is code which calls timer.device/GetSysTime() and stores timeval.tv_secs at 14c(a4).

Maybe it would not crash on exit (or crash less) if timing code in amigaos_thread.c/amigaos_cvar.c wasn't broken. As it looks at the moment what can for example happen is that a timerrequest is pending (unreplied) while it shuts down (CloseDevice). Because of the usual broken timing code which among other things assumes timersig received == timerequest was replied. This is not always so, because a previously aborted timerequest may have left the signal set, because WaitIO() does not always cause the signal to be cleared.

I looked a bit through sources files named "*amiga*".

Timing code is buggy.

After AbortIO() you still need to call WaitIO() otherwise request does not get removed from reply port. Also you should not call AbortIO() on a request which was never SendIO()ed.

When receiving timer signal this does not necessarily mean that the request has completed. Check if request has arrived back at reply port. For example with GetMsg() which does the "remove from reply port", too, which is also missing here.

In "if (include_timers && caughtSignals | 1 << d->timerPort->mp_SigBit)" the | should be an &.


Not related to timer stuff, but if there's things like intuimessages where more than one message can end up at the MsgPort at the same time, then when receving the signal you must loop over and handle all messages on the msgport otherwise you create ~"laggy/delayed" response to events. The task's received-signal-mask gets the signal bit cleared after the Wait() call. It does *not* reflect the is_msgport_empty_or_not state.

I don't know much about this shared objects in AOS4, but shouldn't they show up in exe as "undefined". In Linux

objdump -T `which kate` | grep -i staticmeta | grep -i lineedit

shows:

0000000000000000 DO *UND* 0000000000000000 Qt_5 _ZN9QLineEdit16staticMetaObjectE
0000000000000000 DO *UND* 0000000000000000 _ZN9KLineEdit16staticMetaObjectE

Maybe check with some other AOS4 programs which use shared objects, to see how the shared symbols in the exe appear there.

@kas1e



Assuming example: count=1 == should convert one quad to two triangles, right? (I don't know GL).

But at end of that code block it says "count = ilen" but ilen=count*3/2 which would be 1 in this example. 3/2=1.

@kas1e

What happens if in OpenGLRender.cpp you make COpenGLRender::ActivateHeightFog() function do nothing ("return" at start of function)?

@kas1e

Quote:

It avoids blitting outside left bounds (and thus trashing memory there) because that's what debug output shows it did (negative coords). So the change causes the bitmap to be allocated bigger (wider) and the blits to be offset to the right so that final blit X position of each glyph (char in string) is always >= 0.

Theoretically (weird fonts/languages/accents?) it could still blit outside right/bottom/top side. So to be 100 % safe you would need to check all sides. ~

@kas1e

Crash is more likely second line ("if( (*menu)->parent_entry->show_subsetting )") with parent_entry likely being uninitialized.

Add a line to menu_new() which sets menu->parent_entry to 0. Or change the malloc in there to calloc.

@kas1e

Quick fix (assumes only blitx can be out of bounds (on left side)). Undo previous stuff (kprintf), first:

Try

@kas1e

getStringPixmapFT()/my_draw_bitmap() likely trashes mem when blitting into chunky buffer (data) -> font glyph info/"coords" (bitmap_left) maybe can have values the code does not expect (like negative ones). Because of kerning or whatever. my_draw_bitmap() isn't clipping anything.

It happens because of the way icon dragging (moving the icons sprite like (actually bobs) over the screen) is done by Workbench. It locks all the layers on the screen so that it can draw directly into screen bitmap and the locks prevent other apps from rendering at the same time to prevent gfx trashes.

Theoretically icon dragging could be handled differently by Workbench by doing it like in other OSes where they put the icons in a irregular shaped window (or alpha shaped window with compositing enabled) and move that around. This needs a lot more cpu/gfx power so on things like Classic Amigas would be unusable slow.

Or Workbench could optionally simply not do the LockLayers()/UnlockLayers() calls and user would have to live with small gfx trashes every once and then. There are tricks to repair some of the gfx trashes after dragging is done. Partly automatically, partly by user.

@Hans

Disable gfx card interrupts in reset handler to prevent the situation during soft boot where there could be interrupts coming in but gfx driver is not yet running and can't handle it to ACK the interrupts, so system hangs in interrupt "state"?