umm do you check with snoopy what library or mod did this issue... can be something related using of ram? check on mem/vmem meter if this sites are using much ram and make Odyssey crash, some times jquery make issue with system with low memory.
i see Odyssey crash only on Efika when ram finish because webkit is huge mem eater
Both point to websockets, at least. and It's totally unrelated to js in general, but to the websocket network backend, so basically BCSocketStreamHandleCurl.cpp.
In your case, it seems the socketstream client leads to deleting the socketstream handle itself, but then calls the socketstream again, hence this 0xCCCCCCCC address.
It also happened in MorphOS in some versions before, and the fix was basically to protect the handle with a RefPtr in the right place so that the handle doesn't get deleted. That said, since it crashes on OS4 and not MorphOS, i don't get why it happens, but what's sure is you should debug that piece of code (and the generic WebCore/Modules/websockets code) if you intend to fix it.
Dunno at all what is all about, only see that its m_curlHandle which is 0x0000000 in the SocketStreamHandle::platformClose. Maybe its somehow related to way how websocket's threads created/deleted ? Because for example for os4 port (and before and now) we had to do one more change related to threads to make aos4 version works : in BAL/Types/WTf/BCThreadingWTF.cpp:
It doesn't happen when js is disabled because websockets are js-driven, of course. But your issue is still not about "javascript", but about the websockets backend.
Regarding your thread stuff, it won't have any effect. It all happens in main thread context (it would be different if js workers/shared workers were enabled, but they aren't, for a good reason).
It doesn't happen when js is disabled because websockets are js-driven, of course
Is it necessary to have websockets enabled at all ? I mean, did it give any benefits except html5test.com ? If i will just disable them will everything works as expected just without websockets ?
What is interesting, those websockets seems involved rarely, and even if they calls ones time, no crash happens. For example when i go to html5test.com i have:
And its really so rare i see that debug, can visit about 10 heavy sites with JS, and those sites don't use websockets, and no calls from all those SocketStreamHandle (no surpise that not all sites crashes, so i even didn't notice it at all before).
And exactly same crash if i trying to use "secure websocekts (tls)", of course.
I think that maybe curl should be build somehow different, but then tried with pure curl binary done from my libcurl.a which i use with odyssey, and seems websockets works, etc:
@Fab Omiga !! I fix that crap ! It was indeed didOpenCallback and all what i do its the same as you do for other fucntions, right at top adding protect , i.e.:
// This starts polling for notification.
m_pollTimer.startRepeating(pollInterval);
}
So now on websocket.org i pass both tests for connect (plain and secure ones), as well as bombermine.com works fine now and didn't crashes, as well as mail.yandex.ru works too ! Omiga1200 !
Btw, that bombermine.com seems so far only one site i found which heavy use websockets, i mean really heavy (While with mail.yandex.ru it was just 2 instances). bombermine.com anyway didn't works as it should by default: after i choice "play as guest" it didn't load everything (same on morphos as well, but it works on my win32's chrome). But when i spoof it as chrome, then it works ! (both , on os4 and on mos). What a relief :)
Strange why it didn't crashes same on mos without protect in didOpenCallback, through, but who care :)
@Fab Well,i was too fast to say "it fixed". That protect fix the crash, yes, but websockets still didn't works as they should. I.e. they just disconnects.
If i go to websocket.org/echo.html , then do "connect" on os4 port, then their log form says "disconnect". But if i do same on morphos version, then it say in they log says "connected", and wait till i not press "disconnect" button (through, "Use secure WebSocket (TLS)" also didn't works on morphos and do disconnect, while works on win32's chrome).
So while there is no crash anymore, it isn't here not because all fine, but because it just seems don't do connection.
It i just pure go at bombermine.com and wait till everything loads.
Also tested Joerg's owb : while there is not full websocket implementation its still have some basics as i see by tests, and it still can pass websocket.org/echo.html (tested with plain websocket connections : works. But , with TLS it just crashes with null pointer).
@All Common, where all those skilled ppls who can easy port it all ? Check the files i put in previous post, maybe you will find something.
Edited by kas1e on 2014/2/19 11:20:27 Edited by kas1e on 2014/2/19 11:21:06 Edited by kas1e on 2014/2/19 11:22:30 Edited by kas1e on 2014/2/19 11:24:39 Edited by kas1e on 2014/2/19 11:40:32 Edited by kas1e on 2014/2/19 11:41:57
For sure you know already so you don't need, aniway Just to verify i repeat the test on my system and the websocket.org/echo.html site seems fine on Joerg's OWB 3.32 (atleast no crash pressing the connect/disconnect buttons) but it crash under Odyssey 1.16
Quote:
Crash log for task "OWB" Generated by GrimReaper 53.16 Crash occured in module OWB at address 0x6B53AE6C Type of crash: DSI (Data Storage Interrupt) exception
@samo No needs for those verify-tests of course :) i done them myself already (see previous posts, and for odysseys, and for joerg's owb). And before you says "but i test it on sam, maybe it will be different" : nope, i already collect crashes from all the HW, they all same, and as you can see its all already known what it all about, and for now there no needs for another tests, but fixing of websockets code need it. And of course its the same on 1.16, its wellknown, and by me, and by you, and bugs.os4depot.net know it too.
In other words, instead of repeating of now-non-necessary-tests-as-they-done-and-results-in-previous-posts, just fix that problem with non working websockets and send me diffs :) I.e. not fixing of just crash (as i already do), but making them works as they should on os4 :)
I can just disable websockets at all, and no crashes will be , but then it will luck some functionality in compare with morphos which is suck.
And before you says "but i test it on sam, maybe it will be different..
That was the idea ..
Quote:
In other words, instead of repeating of now-non-necessary-tests-as-they-done-and-results-in-previous-posts, just fix that problem with non working websockets and send me diffs :)
Haha sure just wait some more years until i learn somethings about
@all As no one want to step in, i just enable debug everywhere in the BCSocketStreamHandleCurl and whole websockets, and do 2 test by going to websocket.org/echo.html and press "connect" button.
1 test: with my fix disabled (i.e. original Fab's code):
And no crash, but "disconnected" in the log of websocket connection.
What it mean, is that in both cases websockets for us just didn't works and didn't connects. And for us it crashes and fix need it because some general functionality not works, while for morphos it works , and so they have no crash and have no needs to protect it
Damn, really hate to dig in all of this ! I somehow feel it will be about some opening of ISocket interface somewhere or kind.. Maybe all those recv()/send() in BCSocketStreamHandleCurl should be from ISocket with all necessary initialisation (but tried, and same).
@Scott that make no big sense as all ppls from os4coding are here, and those at hp forum are here too. and basically, only real help in that case can come only from Fab , and maybe from Joerg , and they both here and only them know that code.
@javier that what i think about too, but "mos debug" mean compile mos version of odyssey (as enable debug mean adding of bunch of kprintfs as i do now for os4), and that mean build all the 3d party libs for mos and deal with all that mos related moments. probably if nothing will come in next days will build mos version to compare outputs so can see at least whatshould be and where.
As i see it from debug log, we have just didFailSocketStream() from websockets/WebSocketChannel.cpp , when we do platformSend() from BCSocketStreamHandleCurl.cpp, and code in question imho is that platformSend():
That why i think that just send() fail (and trying ISocket->send() with opening of bsdsocket.library/interface in the socketstreamhandle , etc without luck).
Edited by kas1e on 2014/2/20 16:05:17 Edited by kas1e on 2014/2/20 16:11:57 Edited by kas1e on 2014/2/20 16:24:50
I didn't want to create a new thread, so here's my question.
Am i able to change the search engine used when i type something in the URL field? It always uses google, which i don't want. I searched hi and lo in the Settings but the only Search engine i could change is the one right next to the URL field. (Windows/Search Engines)
Is there a way in 1.16 respectively will there be a way in 1.23 to change this search engine aswell?
Also tested Joerg's owb : while there is not full websocket implementation
It has full support. Of course features added to WebKit after OWB development was stopped by Sand-Labs/Pleyo can't work.
Quote:
@All Common, where all those skilled ppls who can easy port it all ? Check the files i put in previous post, maybe you will find something.
It's very obvious what you are doing wrong, but as long as you don't remove the malware parts (bug #640) from your Odyssey builds, and instead of fixing it even tell users to mess around with the OWB executables breaking features in it, you wont get any help from me any more.
In URL string you can invoke another search engine by using its shortcut (configurable in search engine settings). So for instance, "y blah" to search on youtube or "a blah" to search on aminet.
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
