Porting to AmigaOS4 thread

This is so stupid...

It still crashes at that dynamic cast line in sdl.cpp and then it doesn't.

I have one build where it works and another where it didn't.
I can't get my head around why it work in the one build and not the other, they are completely the same when it comes to using sobjs and source.

Something is different, but i don't know what

Stupid shared objects

@Capehill

Which gcc do you use?
Where did you download it?
Could you please post your libc.so and libstdcc++.so size and date.

Since the crash is always at the same line here
What would I need to add as printf to debug a probably empty variable that is given there?

...and do you maybe know where I could look else and what could causing this?

@Raziel

8.3.0 (-699), it's installed from adtools page.

To debug issue you would need to debug libstdc++. So you need to build your own library too.

Meanwhile I have reported https://github.com/sba1/adtools/issues/77

It might be related to your DSI issue. I have a very pecualiar condition on my system that zero page accesses are not caught (!), so on my system some DSIs go unnoticed (have reported it to Hyperion). ISI might happen if DSI is ignored.

So maybe you can try my simpler example and check does it trigger either DSI or ISI, or nothing?

@Capehill

Thank you.

Will do and report back.

Is there anything else needed to build shared objects (apart from -fPIC, -use-dynld and sometimes -shared)?
I'm suspecting a missing switch in my linker line, probably.

Also, could you post your libc.so and libstdc++.so sizes anyway, please?

And one more thing just, to understand.
If an app uses threading, but I use -athread=single, would the app still work?
iuc -athread=single means only one thread is used, while -athread=native allows more than one thread(?)

Thank you

@Raziel

For creating a shared object:
-fPIC is need to compile files for a shared object (library parts)
-shared is needed when linking the shared object file itself

For using a shared object:
-use-dynld is needed when you want to link an executable file with some shared object (.so instead of .a)

I will check the files at some point but they are really the ones that came with the GCC.

You can try to use -athread=single and I think linker will give you errors if that's a no-go. Generally it's not usable for SDL games, for example, because audio runs in its own thread.

@Capehill

Thank you very much, will check all that and see if I have some mix up in my build lines.

Have commented to your bug item too...too bad

@broadblues


Quote:
Any way i can add/get that easily?

@all

Anyone?

Is intltool available on AmigaOS4 (i guess not as i have looked), because if i try to recompile the source it asks me for that XMLParser stuff...

Thanks

@Raziel

I tested the latest ScummVM and it seems that the internal stack cookie 600000 bytes is not enough. It crashes for me before the menu appears. My default stack is around 132 kilobytes.

If I increase stack to 1000000 and monitor it, it seems that ScummVM is using 69% (690000 bytes) of stack (without game) so it needs more stack.

Please verify this finding and increase the stack cookie value.

@Capehill

Hah, nice catch.

Yes, i have 1024000 in my ScummVM.info set, so this never bit me.

Ranger tells me 700620 Bytes used

So, what would be best?
Go with a small change and increase it to 1024000
or take a secure step and use 2048000?

@Raziel

Ah well, better safe than sorry, 2048000 it is

@Capehill

wrt to fullpipe in scummvm

Would you maybe have time to update your canary and malloc_hack patch to the latest source?

I apllied them and neither do i get into the game nor does it log any canaries (the database in ram: is always empty).

I'm in contact with the engine author and so far we found absolutely nothing which could cause the crash, even the debug logs on his annd my computer are exactly the same, until i crash suddenly.

We could need any pointers we can get.

Thank you

@Raziel

Database is probably empty because book() calls are commented out. At least on my system I can see dead canaries on serial.

Anyway, I have updated the canary patch. Ignore the makefile part.

http://capehill.kapsi.fi/scummvm/canary_patch_nov_2019.patch

Obviously the engine is still broken (endian probably) because sprites are garbage.

@Capehill

Thank you so much.

Yes, thats what i'm trying to tackle with the engine dev tonight, hopfully.

It's great to see that you are still able to reach the game, so not all hope is lost

UPDATE: I still don't see ANY birds...not in ram:, not on serial...what am i doing wrong?

@Capehill

Could you also revise your malloc hack?

@Raziel

Canary patch evolved from malloc one, so malloc patch shouldn't be needed. Try:

nm scummvm | grep malloc

...Make sure that malloc symbol is 'T' and not for example 'U' (undefined).

...Add some more DebugPrintF() calls, for example into hacked malloc() function, to see that it's called.

I tried to clone your repo yesterday but sgit gave me 404 in the end. I will try to fork it some day.

@Capehill

nm scummvm | grep malloc
U malloc
025c66b4 b malloc_hook
01594978 T mpeg2_malloc
0159490c T mpeg2_malloc_hooks

How do i mak sure that it is "T"?

@Raziel

Then my "malloc" is not compiled into binary. Introduce some compiler error in "malloc" function and see if compiler reacts to that. If not, then code is not being compiled and it maybe due to preprocessor switches (#if 0 ... #endif).

@Capehill

Hmm, i added some warning() to
void realloc()
void free()
void malloc()
and all of those warnings pop up when i start the engine, so the code is at least compiled in.


And i did, by mistake, introduce a compiler error (due to the warnings) and it also showed up.

Something is going wrong while executing i'm afraid.

wrt the repo
Yes, after the PR was merged ideleted it again

@Raziel

Quote:

Many of them, too? Thousands?

Can you share your diff?