Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
46 user(s) are online (22 user(s) are browsing Forums)

Members: 0
Guests: 46

more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 11 12 13 (14) 15 16 17 ... 72 »
Re: Odyssey 1.23 progress
Quite a regular
Quite a regular


See User information
@kas1e

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

Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

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.

Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@tlosm

It's not related to memory usage at all.

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@Fab
With enabled debug in BCSocketStreamHandleCurl, going to mail.yandex.ru give me that on serial (include crash) : http://kas1e.mikendezign.com/temp/shi ... shes/handlecurl_debug.txt

Interesting that when JS is disabled, then websockets seems not involved ? At least i can't see when login to mail.yandex.ru without JS all those:

SocketStreamHandle 0x6212DC68 client 0x62338108
createConnection 0x622FE060

and so on.

But once i enable JS , then they come (rarely, just few printfs, but still).

As i see at end of our debug printfs, but before crash, we have:

Quote:

platformClose 0x629DA660 0x00000000
closeConnection 0x00000000
~SocketStreamHandle 0x629DA660
closeConnection 0x00000000


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:

#ifdef __amigaos4__
#include <proto/exec.h>
#include <exec/tasks.h>
#endif

static void threadEntryPoint(voidcontextData)
{
#ifdef __amigaos4__
     
struct Task *t=FindTask(NULL);
     
NewThreadContextcontext reinterpret_cast<NewThreadContext*>(t->tc_UserData);
#else
     
NewThreadContextcontext reinterpret_cast<NewThreadContext*>(contextData);
#endif


Because of all that newlib/calling from same task, etc (because of what we also had to change calling of clipboard hook as well).

Probably not related, but maybe something like this should be done for threads in websockets ?


Edited by kas1e on 2014/2/18 13:45:46
Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

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).

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@Fab
Quote:

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:

Quote:

SocketStreamHandle 0x5BDCBDE0 client 0x5B6CFFB0
createConnection 0x5A45B060
platformClose 0x5BDCBDE0 0x00000000
closeConnection 0x00000000


And no crash.

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).

I even for sake of be 100% sure that its about websockets only, go to http://www.websocket.org/echo.html, and there just press on button "connect" (for ws://echo.websocket.org), and it happy crashes of course with such log:

Quote:

SocketStreamHandle 0x63219B30 client 0x63CE21D8
createConnection 0x63254190
didOpenCallback client 0x63CE21D8
platformSend 0x63219B30
1 m_client 0x63CE21D8
platformClose 0x63219B30 0x63254190
closeConnection 0x63254190
platformClose 0x63219B30 0x63254190
closeConnection 0x63254190
~SocketStreamHandle 0x63219B30
closeConnection 0x63254190

<<CRASH COME>>


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:

Quote:

8/0.RAM Disk:> curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Host: echo.websocket.org" -H "Origin: http://www.websocket.org" http://echo.websocket.org
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://www.websocket.org
WebSocket-Location: ws://echo.websocket.org/
Server: Kaazing Gateway
Date: Wed, 19 Feb 2014 05:59:50 GMT
Access-Control-Allow-Origin: http://www.websocket.org
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: x-websocket-extensions
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol


Wtf then.. Maybe that didOpenCallback ?


@All
Anyone with skills who can help with debug/ideas of what happens with that websockets backend ?

There is files in question:
http://kas1e.mikendezign.com/temp/shit_crashes/files/


Edited by kas1e on 2014/2/19 6:13:11
Edited by kas1e on 2014/2/19 6:15:15
Edited by kas1e on 2014/2/19 6:16:49
Edited by kas1e on 2014/2/19 6:20:21
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@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.:

void SocketStreamHandle::didOpenCallback(Timer<SocketStreamHandle>*)
{
    
D(kprintf("didOpenCallback client %p\n"m_client));
    
    
RefPtr<SocketStreamHandleprotect(this);

    
ASSERT(m_state == Connecting);
    
m_state Open;
    if(
m_clientm_client->didOpenSocketStream(this);

    
// 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 !

Resized Image

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 :)

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
Omiga!

I like these posts! Bug squishing supremo

AmigaOne X1000.
Radeon RX550

http://www.tinylife.org.uk/
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@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.

I also do make whole debug of bombermine.com with that "fix" in didOpenCallback(), and that what we have (maybe you find something unusual there, like "select 0" everywhere or so): http://kas1e.mikendezign.com/temp/shi ... shes/bombermine_debug.txt

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
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
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

Register dump:
GPR (General Purpose Registers):
0: 6B53ADB4 49ECE920 00000000 49ECE92C 47299B98 00000000 000000F0 081C60BC
8: 3ED75760 CCCCCCCC 01A50000 021BDC66 0000015C 4A338740 00000000 4A330B08
16: 4A3323C8 4A330B64 DEAD0077 4A3323C8 558D0000 49ECEC78 53F3D024 4A330B64
24: 49ECEC78 53F3D024 000003F0 3F749428 49ECE930 49ECE92C 4A2A7DFC 3ED75778


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0 0 65
4: 416 740 1102 1102
8: 416 600 416 362
12: 740 1.39282e+09 0 0
16: 0 0 0 0
20: 0 0 0 1.61895e-319
24: 0 0 1.08646e-311 -1.17478e+229
28: 0 0 1.39282e+09 1.39282e+09

FPSCR (Floating Point Status and Control Register): 0xA2002100


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x54541390
Instruction Pointer (ip) : 0x6B53AE6C
Xtended Exception (xer) : 0x01821028
Count (ctr) : 0x00000000
Link (lr) : 0x00000000
DSI Status (dsisr) : 0x0183F248
Data Address (dar) : 0x00000000



680x0 emulated registers:
DATA: 58C5658E 00000003 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 49ECE0C0
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x6B53AE6C belongs to module "OWB" (PowerPC)
Symbol: _ZN7WebCore16WebSocketChannel19didOpenSocketStreamEPNS_18SocketStreamHandleE + 0x140 in section 1 offset 0x0108FE48

Stack trace:
_ZN7WebCore16WebSocketChannel19didOpenSocketStreamEPNS_18SocketStreamHandleE()+0x140 (section 1 @ 0x108FE48)
_ZN7WebCore16WebSocketChannel19didOpenSocketStreamEPNS_18SocketStreamHandleE()+0x88 (section 1 @ 0x108FD90)
_ZN7WebCore5TimerINS_18SocketStreamHandleEE5firedEv()+0x30 (section 1 @ 0x110FC88)
_ZN7WebCore12ThreadTimers24sharedTimerFiredInternalEv()+0x140 (section 1 @ 0x17FD90)
_ZN7WebCore12ThreadTimers16sharedTimerFiredEv()+0x40 (section 1 @ 0x17FDF8)
_ZN7WebCore17fireTimerIfNeededEv()+0x38 (section 1 @ 0x16E9EC)
_ZN14WebViewPrivate21fireWebKitTimerEventsEv()+0x10 (section 1 @ 0xCB144)
_ZN7WebView21fireWebKitTimerEventsEv()+0x14 (section 1 @ 0xA8804)
_ZL28handleMM_OWBApp_WebKitEventsP6IClassPmP4_Msg()+0x90 (section 1 @ 0x44C4)
_ZL8dispatchP6IClassPmP4_Msg()+0x460 (section 1 @ 0xE740)
CustomClassDispatcher()+0xa0 (section 1 @ 0x41B4)
native kernel module intuition.library.kmod+0x0001824c
native kernel module intuition.library.kmod+0x00018470
native kernel module intuition.library.kmod+0x00008448
native kernel module intuition.library.kmod+0x00008088
_Z9main_loopv()+0x1e0 (section 1 @ 0x550)
main()+0xac (section 1 @ 0xFD4)
native kernel module newlib.library.kmod+0x000020ac
native kernel module newlib.library.kmod+0x00002d5c
native kernel module newlib.library.kmod+0x00002ef0
_start()+0x170 (section 1 @ 0x16C)
native kernel module dos.library.kmod+0x00024cd0
native kernel module kernel+0x0003b4b0
native kernel module kernel+0x0003b530

PPC disassembly:
6b53ae64: 809e8024 lwz r4,-32732(r30)
6b53ae68: 7fa3eb78 mr r3,r29
*6b53ae6c: 83890044 lwz r28,68(r9)
6b53ae70: 48250c4d bl 0x6B78BABC
6b53ae74: 7fe3fb78 mr r3,r31

System information:

CPU
Model: AMCC PPC440EP V1.3
CPU speed: 799 MHz
FSB speed: 133 MHz
Extensions:

Machine
Machine name: Sam440EP
Memory: 1048576 KB
Extensions: bus.pci


Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@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.

@All
Is there no one who can fix it ? I uploaded files there:
http://kas1e.mikendezign.com/temp/shit_crashes/files/


Edited by kas1e on 2014/2/19 15:44:18
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
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

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@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):

Quote:

WebSocket 0x630EDCE0 connect() url='ws://echo.websocket.org?encoding=text'
WebSocketChannel 0x62FCBAB8 connect()
SocketStreamHandle 0x630EDD80 client 0x62FCBAB8
createConnection 0x630EDEB8
didOpenCallback 0x630EDD80 client 0x62FCBAB8
WebSocketChannel 0x62FCBAB8 didOpenSocketStream()
platformSend 0x630EDD80
1 m_client 0x62FCBAB8
WebSocketChannel 0x62FCBAB8 didFailSocketStream()
platformClose 0x630EDD80 0x630EDEB8
closeConnection 0x630EDEB8
WebSocketChannel 0x62FCBAB8 didCloseSocketStream()
WebSocket 0x630EDCE0 didClose()
WebSocketChannel 0x62FCBAB8 disconnect()
platformClose 0x630EDD80 0x00000000
closeConnection 0x00000000
~SocketStreamHandle 0x630EDD80
closeConnection 0x00000000

and then CRASH (i.e. as we have it now in 1.16).



2 test: with my fix enabled:

Quote:

WebSocket 0x6338AF88 connect() url='ws://echo.websocket.org?encoding=text'
WebSocketChannel 0x633CA3F0 connect()
SocketStreamHandle 0x633CF400 client 0x633CA3F0
createConnection 0x62F6A060
didOpenCallback 0x633CF400 client 0x633CA3F0
WebSocketChannel 0x633CA3F0 didOpenSocketStream()
platformSend 0x633CF400
1 m_client 0x633CA3F0
WebSocketChannel 0x633CA3F0 didFailSocketStream()
platformClose 0x633CF400 0x62F6A060
closeConnection 0x62F6A060
WebSocketChannel 0x633CA3F0 didCloseSocketStream()
WebSocket 0x6338AF88 didClose()
WebSocketChannel 0x633CA3F0 disconnect()
platformClose 0x633CF400 0x00000000
closeConnection 0x00000000
~SocketStreamHandle 0x633CF400
closeConnection 0x00000000


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).

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@kas1e

Have you posted this problem over on the Hyperion forums, or on OS4coding? I think you may get better results there.


Scott

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

And what does MOS Odyssey debug_output/show with:

1 test: with my fix disabled (i.e. original Fab's code)


Maybe we can "see" if there is some difference between OS4 & MOS Odyssey (apart of crashing/not_crashing/working/not_working).

Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@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():

Quote:

ssize_t lengthSend = ::send(socket, (UBYTE *)data, length, 0);
if (lengthSend < 0) {
D(kprintf("1 m_client %p\n", m_client));
if(m_client) m_client->didFailSocketStream(this, SocketStreamError(errno));
platformClose();
return 0;
}


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
Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@kas1e

You can try to change the timeouts on the socket.

setscokopt( sockfd, SOL_SOCKET, SO_RCVTIMEO, &TimeVal, SizeOf(TimeVal) );

and

setscokopt( sockfd, SOL_SOCKET, SO_SNDTIMEO, &TimeVal, SizeOf(TimeVal) );

Also check errno, In case you don't, maybe get a useful error.


Go to top
Re: Odyssey 1.23 progress
Home away from home
Home away from home


See User information
@all

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?

Thanks a lot for the ongoing support

Go to top
Re: Odyssey 1.23 progress
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:
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.

Go to top
Re: Odyssey 1.23 progress
Just popping in
Just popping in


See User information
@Raziel

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.

Go to top

  Register To Post
« 1 ... 11 12 13 (14) 15 16 17 ... 72 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project