I do get a lot of LIBS:muimaster.library:GroupDispatcher lately (since the updates) but that might be only me and i also don't have a reproducable case yet.
It surely can be rewriten on amigaos4 native probabaly, as we can expect that today's DOS should do it all what asyncio do. Its just for MorphOS and AmigaOS that all used offten, and it just works for os4 port as well, without needs to tinkering with "if our public DOS can do that all already what asyncio do, and if it worth to worry about at all".
Quote:
I do get a lot of LIBS:muimaster.library:GroupDispatcher lately (since the updates) but that might be only me and i also don't have a reproducable case yet.
Be sure you use beta02, and be sure you use latest mui. But if both are meet, then it probabaly that one:
So try to save crashlogs , and compare if they the same, as well as take latest debug version Thore attach to the ticket and try to follow his steps he ask to provide more usefull crashlogs.
Found a general bug in address bar, it's not a new one as i can reproduce it in every versions of owb
To reproduce it, do this step passages:
1) Identify your browser as IPad 6.1 2) Open Google, and type something to search, for example: "Odyssey Web Browser aros" 3) Now in Google search, choose "image" (so to search for images the text you typed) 4) When thumbnails will be loaded, right click into any of that image and select --> open image in new tab
Have the debug versions installed now for some time, can't get the crash anymore. Either because of the slowdown due to the debug builds or there was some "fix" which, well "fixed" it.
Seems that it loads the picture from a stored database or something like that. Url start with data:image/jpeg;base6 ... and contains more than 16000 characters!
Indeed you are right .. just selected with copy and paste one of that line-url and got a crazy quantity of 12304 chars ! Means Odyssey seems not able to manage such extra long urls and go mad :)
However it doesn't seems a limitation in other Amiga browsers as just tried the same with NetSurf and everything worked with no glitch at all, so only OWB seems affected to ,,, i'll report it as MUI bug eventually
Seems that it loads the picture from a stored database or something like that. Url start with data:image/jpeg;base6 ... and contains more than 16000 characters!
The URL literally has a JPEG image base64 encoded in it. That's what "data:image/jpeg;base64=..." means (where ... is the image data). No wonder it's ridiculously long!
That's a very silly way of submitting an image to a server. Odyssey should still be able to handle it, though.
Trying latest version od Odyssey Web Browser and it feels faster. I can actually watch some html5 youtube videos. Thank you all and please keep updating it.
@kas1e Downaloaded latest Odyssey from github and when trying to compile/build I get:
...
[ 32%] Building CXX object Source/WebCore/CMakeFiles/webcore.dir/__/__/BAL/Image
Decoder/WebCore/WK/BCImageDecoderWK.cpp.obj
In file included from /amiga/Odyssey/odyssey-r155188-1.23/BAL/ImageDecoder/WebCore/WEBP/WK/BCWEBPImageDecoderWK.cpp:30:
/amiga/Odyssey/odyssey-r155188-1.23/build/generated_link/BAL/WEBPImageDecoder.h:36:10: fatal error: webp/decode.h: No such file or directory
#include "webp/decode.h"
^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Source/WebCore/CMakeFiles/webcore.dir/build.make:13117: Source/WebCore/CMakeFiles/webcore.dir/__/__/BAL/ImageDecoder/WebCore/WEBP/WK/BCWEBPImageDecoderWK.cpp.obj] Error 1
make[2]: *** Se espera a que terminen otras tareas....
In file included from /amiga/Odyssey/odyssey-r155188-1.23/BAL/ImageDecoder/WebCore/WK/BCImageDecoderWK.cpp:37:
/amiga/Odyssey/odyssey-r155188-1.23/build/generated_link/BAL/WEBPImageDecoder.h:36:10: fatal error: webp/decode.h: No such file or directory
#include "webp/decode.h"
^~~~~~~~~~~~~~~
compilation terminated.
@Javier And you should update whole SDK dir, as there was updated curl, openssl, rtmp, freetype, xml2 and xslt and that webp, all new includes/libs are in SDK now on github, so both should be cloned.
@All Dont forget to update SDK all the time from github, i offten update it currently.
Atleast compared to usual crashes this one seems more identicable
Quote:
Crash log for task "Odyssey" Generated by GrimReaper 53.19 Crash occured in module kernel at address 0x0181653C Type of crash: DSI (Data Storage Interrupt) exception Alert number: 0x80000003
@Samo Probabaly that one which K-L got some times, so if it indeed just cairo itself, and not Odyssey's code, then updating cairo to newer version may help.
Yes possible, but don't know .. with the old version on os4depot i never had such kind of crash and i had checked/saved dozen of that logs .. first time i see this one is with this beta 2 Aniway, updating to new cairo will worth for sure, hope it helps solving this aswell
Yes possible, but don't know .. with the old version on os4depot i never had such kind of crash and i had checked/saved dozen of that logs .. first time i see this one is with this beta 2
As you can see in readme for beta2 all what was changed its enabling of webp, new spoof agents and new freetype/xml/xstl. The only thing which somehow may be related is new freetype. But then, is it worth to rollback on old one, because it maybe cause that issue ?
If that sort of bugs when-one-visit-some-site was always easy reproduced, that can be somehow at least consider to fix , but when its random..
Webkit is full of bugs that for sure, and all those 3d party libs full of memory leaks and all sort of bugs that for sure too (its enough to check changelogs of all those 3d party libs, to see how many memory leaks they fix , and probabaly how many they introduce). Updating one or another lib will always bring something new : good and bad.
And i am sure we have there lots of memory trashing issues which can manifest in different areas too. They just shifts once new library/code added/removed.
In other words, what can we do there ? If your cairo-crash is random, how can we fix it ?
We can hope updating to new Cairo will solve some issues (and bring new ones, of course !:) ). Maybe new cairo will works better with new freetype as well. But nothing else can be done from my side at least, as fixing webkit's code is out of my skills surely. Expectually when bugs is random.