Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the view to Minibrowser and adding few buttons #17

Closed
wants to merge 30 commits into from
Closed

Adding the view to Minibrowser and adding few buttons #17

wants to merge 30 commits into from

Conversation

RAJAGOPALAN-GANGADHARAN
Copy link

No description provided.

RAJAGOPALAN-GANGADHARAN and others added 28 commits May 18, 2019 16:30
Add a static_assert to make sure pid_t fits there.
Add conversion functions but I think they will not be needed (C integer
promotion will do the magic)
Who wants to use fork/exec when we have much nicer native APIs?

This does not work yet because we need to add a MIME signature to the
launched executables (using an rdef/rsrc file), as I decided to launch
them by MIME signature rather than absolute path.

I trie the previous code and it was crashing before the web process
would even start to run. Let's start with that before we move on to
setting up IPCs.
"YOLO" isn't an helpful log message.
So we notice it when we get it to run and do things.
With this I see that the web process is currently not started at all...
We need a MIME signature so the roster can find it.
…BRoster

I guess the problem was it doesnt consider null as a good arguement just a marker so we need to pass i-1 as the arg count. This briefly
allows me to launch the webprocess app and i was able to see the debug messages on the terminal itself.
Initial implementation of IPC for haiku will add it to description each time i amend
1)added empty functions
2)fixed building issues and successfully created a connection between webprocess
3)Added a message handler to look out for incoming messages to runloop
4) Created new aux support so we can attach all handlers to the main apps looper
1)Added a message stashing feature so it stashes the messages and interprets them when the loop is ready to run
2)Now have to fix connection between network and webprocess
This time used maps to store loopers and BApplications to forward message to appropriate loopers
1) Created a message from ui process to network process that notifies the pid of webprocess
2) Successfully created networkconnectionToWebProcess
3) Replying back to webProcess is not working(to be fixed - i should probably take help from webkit people as im pretty lost)
1) Added NetworkSession so it doesnt crash
2) Added missing run loop getter
1)This makes few important changes in adding the view
2)Partial mouse events which is kept aside now as main focus is put on webpage rendering
1) Few callbacks for finished loading and forward and backward stop etc is now fully functional
2) status text is partially done
3)shared memory done with mapping part pending(i need to understand a little bit more)
@pulkomandy pulkomandy force-pushed the webkit2 branch 2 times, most recently from 0709dc7 to ed03ae4 Compare June 15, 2019 21:24
@pulkomandy pulkomandy force-pushed the webkit2 branch 2 times, most recently from cc92d43 to e34d884 Compare June 17, 2019 19:12
@RAJAGOPALAN-GANGADHARAN RAJAGOPALAN-GANGADHARAN deleted the widget-iteration-1 branch June 29, 2019 19:11
pulkomandy pushed a commit that referenced this pull request Jan 12, 2020
…wind and lldb.

https://bugs.webkit.org/show_bug.cgi?id=205050

Reviewed by Michael Saboff.

Before this patch, the stack trace from inside a probe function is cut off at ctiMasmProbeTrampoline:

    (lldb) bt
    * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef)
        ...
        frame #4: 0x0000000100824607 JavaScriptCore`WTF::Function<void (JSC::Probe::Context&)>::operator(this=0x000000010b88bd00, in=0x00007ffeefbfd400)(JSC::Probe::Context&) const at Function.h:79:35
        frame #5: 0x0000000100823996 JavaScriptCore`JSC::stdFunctionCallback(context=0x00007ffeefbfd400) at MacroAssembler.cpp:53:5
        frame #6: 0x000000010082701e JavaScriptCore`JSC::Probe::executeProbe(state=0x00007ffeefbfd480) at ProbeContext.cpp:51:5
        frame #7: 0x000000010082614b JavaScriptCore`ctiMasmProbeTrampoline + 299
    (lldb) 

After this patch, we'll now get the full stack trace from inside the probe function:

    (lldb) bt
    * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef)
        ...
        frame #4: 0x0000000100826d17 JavaScriptCore`WTF::Function<void (JSC::Probe::Context&)>::operator(this=0x0000000106b878f8, in=0x00007ffeefbfd400)(JSC::Probe::Context&) const at Function.h:79:35
        frame #5: 0x0000000100826106 JavaScriptCore`JSC::stdFunctionCallback(context=0x00007ffeefbfd400) at MacroAssembler.cpp:53:5
        frame #6: 0x000000010082986e JavaScriptCore`JSC::Probe::executeProbe(state=0x00007ffeefbfd480) at ProbeContext.cpp:51:5
        frame #7: 0x00000001008289a2 JavaScriptCore`ctiMasmProbeTrampoline + 338
        frame #8: 0x0000466db28025be
        frame #9: 0x0000000100754ffc JavaScriptCore`llint_entry at LowLevelInterpreter.asm:994
        frame #10: 0x0000000100738173 JavaScriptCore`vmEntryToJavaScript at LowLevelInterpreter64.asm:307
        frame #11: 0x0000000101489307 JavaScriptCore`JSC::JITCode::execute(this=0x0000000106ba1520, vm=0x0000000106d00000, protoCallFrame=0x00007ffeefbfd9b8) at JITCodeInlines.h:38:38
        frame #12: 0x0000000101488982 JavaScriptCore`JSC::Interpreter::executeProgram(this=0x0000000106bfd1f8, source=0x00007ffeefbff090, (null)=0x000000010d0e0000, thisObj=0x000000010d0e8020) at Interpreter.cpp:847:51
        frame #13: 0x00000001017d1f9c JavaScriptCore`JSC::evaluate(globalObject=0x000000010d0e0000, source=0x00007ffeefbff090, thisValue=JSValue @ 0x00007ffeefbfef60, returnedException=0x00007ffeefbff0b0) at Completion.cpp:146:38
        frame #14: 0x000000010005838f jsc`runWithOptions(globalObject=0x000000010d0e0000, options=0x00007ffeefbff620, success=0x00007ffeefbff48b) at jsc.cpp:2670:35
        frame #15: 0x000000010002a0da jsc`jscmain(this=0x00007ffeefbff5a0, vm=0x0000000106d00000, globalObject=0x000000010d0e0000, success=0x00007ffeefbff48b)::$_6::operator()(JSC::VM&, GlobalObject*, bool&) const at jsc.cpp:3157:13
        frame #16: 0x0000000100006eff jsc`int runJSC<jscmain(int, char**)::$_6>(options=0x00007ffeefbff620, isWorker=false, func=0x00007ffeefbff5a0)::$_6 const&) at jsc.cpp:3003:9
        frame #17: 0x0000000100005988 jsc`jscmain(argc=10, argv=0x00007ffeefbff6c8) at jsc.cpp:3150:18
        frame #18: 0x000000010000575e jsc`main(argc=10, argv=0x00007ffeefbff6c8) at jsc.cpp:2498:15
        frame #19: 0x00007fff6cfc4da9 libdyld.dylib`start + 1
        frame #20: 0x00007fff6cfc4da9 libdyld.dylib`start + 1
    (lldb)

The difference is that the x86_64 ctiMasmProbeTrampoline now uses the standard
function prologue, and keeps %rbp pointing to trampoline function's semblance of
a frame that libunwind can understand while it calls the probe function.

* assembler/MacroAssemblerX86Common.cpp:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@253320 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants