I'm so confused. So have you tested ScummVM with a high stack size with libcurl.so.12, or not? I thought your video was showing everything working fine with libcurl.so.12
Mismatching .so files can cause all sorts of problems. For example, libcurl.so.11 will be looking for libcrypto.so.1 and libssl.so.1, not libcrypto.so.3 and libssl.so.3. Also, libcurl.so.12 is built against OpenSSL v3, not OpenSSL v1.1. Also the latest build of librtmp.so.1 should be expecting OpenSSL v3 libraries as well.
Files in PROGDIR:SObjs/ will be found before it looks in SYS:SObjs/. Everything needed for ScummVM should be in PROGDIR:SObjs/
If you've been renaming things or moving files around in a way where the newer libcurl is trying to use the older openssl, it might not be ABI compatible and cause crashes.
So if you haven't tried ScummVM with all the intended files (no files renamed or overwritten, and nothing from SYS:SObjs/ being used), and with a high stack size, then please try that. That was the point of the test, to see if a higher stack size fixes the issue.
Also, you said the crash was always within libcurl, but is it always the same address space within libcurl? I tried checking what address 0x7A3BAEF0 and 0x7A3BAEE0 were in libcurl.so.12 using addr2line but they don't seem to be valid, making me think the issue was memory corruption or something similar (sometimes all that's needed to fix a DSI is a higher stack size). From the sounds of it, there's no problem unless you're running Odyssey/YT first.
I'm assuming you're on the latest OS4.1 FE (Update 2 + updates)?
Edited by MickJT on 2024/2/20 20:15:10 Edited by MickJT on 2024/2/20 20:22:25 Edited by MickJT on 2024/2/20 20:50:31 Reason: updated hex addresses
Perhaps I expressed myself a little incorrectly and you didn't understand correctly. ScummVM 2.8.0 Os4Depot uses libcurl.so.12 with this version it leads to reproducible DSI and crashes without renaming or replacing files. As soon as this version is replaced by version 11 there are no problems.
I have not yet tested ScummVM with libcurl.so.12 and stack 4000000. Only with libsurl.so.11. I will repeat the tests with an increased stack for ScummVM and libcurl.so.12. Without having renamed or replaced files.
So. It only crashes after you've been running something else like Odyssey or YT.rexx? I also use WinUAE and get crashes sometimes that didn't occur on real hardware (unfortunately I don't have working real hardware to test on anymore). I haven't tried running ScummVM myself yet.
Tested with ScummVM 2.8.0 (Os4Depot) no files changed increased stack size standard 1024000 to 4000000 with libcurl.so.12...DSI Reproducible with Odyssey.
I can also publish some additional Protocols so that you can take a look at them.
The same problems also occur on real hardware, please follow this thread and please do not compare Qemu Peg2/AmigaOneXE/Sam460 with WinUae, it does not emulate NG hardware. An example: Run SysMon or lspci under WinUae and it will crash and many other things that access the hardware directly. But it's not an attack on WinUae, what I want to say is that NG hardware emulation works a little better.
Is it still the same address in the stack trace? 0x7A3BAEF0 ? If I use ppc-amigaos-addr2line -e libcurl.so.12 -j .text 0x7A3BAEF0 I only get "??:0" which doesn't help! And libcurl.so.12 should be built with debug symbols.
I don't know what you mean by "additional protocols".
Perhaps updating libcurl again will magically fix things. I'll look at that later. .... but to be clear, there's no problem when you don't run Odyssey first?
I also don't know how you managed to get this info in post #492:
ppc-amigaos-addr2line -e scummvm -j .text 0xDE9FB0 I also get ??:0, but scummvm is built without debug symbols. Were you using a different scummvm binary than the one on OS4Depot?
I don't know what you mean by "additional protocols".
Balaton has everything available with BBoot and "-append" so I can debug under Qemu just as someone would under real hardware, only it's not as complicated.
Quote:
Perhaps updating libcurl again will magically fix things. I'll look at that later. .... but to be clear, there's no problem when you don't run Odyssey first?
Exactly if Odyssey is not running beforehand there are no problems with ScummVM. Only after the Odyssey is running are there problems, some users also reported that they had previously used AmigaAmp, perhaps music streaming?
Quote:
I also don't know how you managed to get this info in post #492:
As already mentioned, debugging with Bboot -append debug level 20 lets me see everything when debugging under AmigaOs4.1. Even if programs are executed under AmigaOs4.1, it is recorded and I can read it in the serial console. You can't debug this with WinUae even if it uses the Qemu plugin, this function is simply missing and it only emulates PowerPC 604e and not NG hardware. That's what I tried to explain. Quote:
If I run
ppc-amigaos-addr2line -e scummvm -j .text 0xDE9FB0 I also get ??:0, but scummvm is built without debug symbols. Were you using a different scummvm binary than the one on OS4Depot?
No, I used ScummVM from Os4depot in version 2.8.0.
Edited by Maijestro on 2024/2/20 21:33:51 Edited by Maijestro on 2024/2/21 8:45:10
MickJT wrote:Is it still the same address in the stack trace? 0x7A3BAEF0 ? If I use ppc-amigaos-addr2line -e libcurl.so.12 -j .text 0x7A3BAEF0 I only get "??:0" which doesn't help! And libcurl.so.12 should be built with debug symbols.
If I only use the DSI internally from AmigaOs4.1, the same address is shown as yours, but the address is different via the serial output with Debug 20.
But still it points to libcurl.so. So I guess this is where the problem lies. I'm not familiar with addresses and conflicts because I'm not a programmer.
DSI AmigaOs4.1 output:
module Download:Testen/ScummVm2.8.0/install/sobjs/libcurl.so.12 at 0x76519EF0 (section 0 @ 0x8AA94)
Serial output debug level 20:
module Download:Testen/ScummVm2.8.0/install/sobjs/libcurl.so.12 at 0x7A723EE0 (section 0 @ 0x8AA84)
could you do the test with the prebuild i provided?
the release version doesnt have the debug flags compiled in and will always resukt in ?? addresses
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
I think it might help more to get the debug log from the Grim Reaper More... button then save debug log or something like that than looking at kernel logs. (Unless the crash log is also printed on serial with debug logs redirected there.)
balaton wrote:I think it might help more to get the debug log from the Grim Reaper More... button then save debug log or something like that than looking at kernel logs. (Unless the crash log is also printed on serial with debug logs redirected there.)
I've already tried that and yes the crash log is also redirected via the serial port and it also seems to be a bit more accurate.
If I use ppc-amigaos-addr2line -e libcurl.so.12 -j .text 0x7A3BAEF0 I only get "??:0" which doesn't help!
0x7A3BAEF0 is the memory address on Maijestro's system, which is of course different to your system, and even different each time you run an executable on the same system. You have to use the offset in the .text segment instead, for example something like "addr2line -e libcurl.so.12 -j .text 0x8AA94".
@balaton Stack traces of crashes are in the serial debug output as well. Grim Reaper's "more" may resolve symbols the serial output version doesn't include, but all you need is the offset in the .text section of the executable/library/sobj anyway and can get the rest with tools like addr2line, readelf, etc.
@Maijestro Using DebugLevel 20 doesn't make sense, unless you are beta testing a kernel and are told by the kernel developers to use such a high debug level, and only slows down you system a lot due to the huge amount of debug output. For debugging applications using a DebugLevel higher than 5 usually doesn't include more information which could help the application developper, in most cases even DebugLevel <= 3 is enough.
Using DebugLevel 20 doesn't make sense, unless you are beta testing a kernel and are told by the kernel developers to use such a high debug level, and only slows down you system a lot due to the huge amount of debug output. For debugging applications using a DebugLevel higher than 5 usually doesn't include more information which could help the application developper, in most cases even DebugLevel <= 3 is enough.
Thanks for the little reading, I still have a lot to learn how things are done under NG Hardware and AmigaOs4.1. I will keep it in mind for the future....thanks
@Raziel
On their original source where they usually provide their test builds I am not able to download anything. Can you please check this ? Or has the link changed....?
Ok...so a lot of ground to cover, please bear with me.
1) Nope, nothing special, just do your usual testing where you reach the crash, save the log and post it here or over at the crashlog site of os4depot.net
2) Unfortunately the test build was deleted from the share...i have to do a new one when i get home (end of next week) You could try to get a daily build over at scummvm.org, but i'm not sure if their builds are debug builds (also their builds doesn't have all the features compiled in, which may taint the result, but it would be better than nothing - i don't want to slow down the momentum, now that @balaton is here as well)
3) Just for the sake of completeness, could you, if time permits, compile a list of crashes with their exact steps to reproduce? I'd like to do a comparision to rule out shortcomings of the internet access under emulation - it might still be not 100% accurate/error prone and could possibly produce crashes where there are none on native hardware) Not that i say there are, just to be sure...and if there are emulation triggered bugs, you could post them to the WinUAE bugtracker instead...
Thanks a lot
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
Raziel wrote:@Maijestro Ok...so a lot of ground to cover, please bear with me.
Don't stress yourself, I'm waiting for your test build and will test it at my leisure For now there is a WorkRound for libsurl.so.12 by replacing it with version 11 which makes ScummVM work very well.
Quote:
1) Nope, nothing special, just do your usual testing where you reach the crash, save the log and post it here or over at the crashlog site of os4depot.net
I will then make the protocols available here, which is why we have this forum.
Quote:
3) Just for the sake of completeness, could you, if time permits, compile a list of crashes with their exact steps to reproduce? I'd like to do a comparision to rule out shortcomings of the internet access under emulation - it might still be not 100% accurate/error prone and could possibly produce crashes where there are none on native hardware) Not that i say there are, just to be sure...and if there are emulation triggered bugs, you could post them to the WinUAE bugtracker instead...
Don't be angry with me, but I would like to briefly explain the differences between the two emulations WinUae and Qemu.
WinUae:
Deals exclusively with 68k emulation up to Amiga 4000 with extended turbo cards PPC and is developed by Toni Willen. A Qemu plugin is also used for PPC emulation, but it is very old.
Qemu:
Deals exclusively with the first generation of NG hardware AmigaOneXe/Pegasos2/Sam460 and is developed by Balaton Zoltan.
Of course there can always be bugs under emulation that don't exist on real hardware, but since I use Qemu, using the WinUae bug tracker would be the wrong way to go.
Otherwise all bugs have already been detected on real hardware:
I can also confirm that the first start of ScummVM is a bit bumpy, but if I use an already configured .ini file there are no problems. And the main problem with libcurl.so.12 which we have recognized and leads to different crashes under real hardware, as well as under Qemu/Peg2. I also noticed that your installer creates a ScummVM.info in the installed directory without a folder. But let's take care of the main problem first...
It would of course be helpful if someone with real hardware can confirm that if ScummVM 2.8.0 (Os4Depot) can run better by replacing libcurl.so.12 with version 11.
also noticed that your installer creates a ScummVM.info in the installed directory without a folder.
that is the folder icon which i cannot install otherwise. amigaos installer doesnt know about the directory *above* the install directory, hence the folder icon is placed *inside* the install directory.
if a new version is updated through amiupdate that problem isnt there.
nothing i can do about
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
MickJT was kind enough to recompile libcurl.so.12 and it works perfectly with ScummVM 2.8.0. I can't reproduce any DSI or crashes like I could before. Thanks for the recompile, good job
@Raziel
I'm not sure but libcurl.so is generally responsible for downloading the icon packs, was this function ever added to ScummVM? So did it used to work with ScummVM or was this function never there.
I only ask because I have tested it with the new version libsurl.so.12 from MickJT and it only gives me one error request.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
