Thanks @leavengood, I’ll refer your info on Trac ticket/review request.
BTW, loading 1GBs+ debug info takes minutes and results exauhst 16GBs memory of my PC
Thanks @leavengood, I’ll refer your info on Trac ticket/review request.
BTW, loading 1GBs+ debug info takes minutes and results exauhst 16GBs memory of my PC
Some things never change
Feew…, that’s insane…, they really should split this beast into small, more manageable libs.
I feel like we keep seeing that sort of thing for browsers or other large code and I would think the Debugger code could be adjusted not to do that. Maybe some things could be more lazily loaded or maybe the data structures could be adjusted to use less memory.
Many times when things are coded for smaller or normal sizes they fall down with greatly larger things (like text editors that can’t open large files.) But sometimes that can be fixed without a huge amount of effort. But I personally don’t know enough about Debugger to know of that is the case or not. Knowing Haiku developers there are probably some TODO
comments suggesting improvements here
But I suggest seeing if it can be fixed rather than having us constantly hitting this case for large code bases and just throwing up our hands in frustration (or needing absurd amounts of RAM.)
I stopped debugging the Debugger itself, and I started enjoying to debug why the app crashes (syscall fails abnormally) when it spawns new thread in the spawned thread function, for now.
But after I frustrated enough to wait minutes per debug session, probably I will be back to debug the Debugger again…
When debugging the Debugger I noticed it takes long to load .debug_info section
(maybe it is the meat of the DWARF), and to notify UI that debug info loaded that I guess there is the place the Debugger Kit passes loaded enormous data to the UI.
Maybe loading .debug_info partially for example in LRU algorithm is easier but the communication between the kit and the app looks harder. Probably some refactoring will be needed.
You may be able to debug things using strace
here, it will show all syscalls (or just individual ones you select), their parameters, and return values. It doesn’t need to load the debug information, so it’s much faster to start.
As far as I understand the newer DWARF formats focused on improving memory and performance.
Hard to say though, at least a few improvements:
DWARF 4 changes: DWARF 4 Standard
DWARF 5 changes: DWARF Version 5
If all the libraries are still loaded in the executable, this will just make things more complicated (loading many small libraries will be slower than loading one large library).
Thanks for your advice, I will debug some more to identify what the situation the problem occur (the intent of code that I didn’t grab well), after that I try strace
with nightly and make a ticket about this.
I wanted stick with R1/beta4 as development environment for stability, but there may be some problem to fix in OS side.
Hi, I’m preparing to submit my first patch to Haiku.
(EDIT: of course, not for the firefox itself, but for the Debugger I want submit soon…)
I am following the steps of Get the Haiku Source Code / Pushing Patches to Haiku 101 | Haiku Project, but in the “Cloning repositories from Gerrit” step, scp
command fails to retrieve commit hook script.
Is this a known problem? Could anyone tell me any workaround?
Command verbose output is (I believe this output doesn’t contain private secret not to be shared):
~/src> scp -v -p kenz-gelsoft@git.haiku-os.org:hooks/commit-msg "haiku/.git/hooks/"
Executing: program /packages/openssh-9.3p1-1/.self/bin/ssh host git.haiku-os.org, user kenz-gelsoft, command sftp
OpenSSH_9.3p1, OpenSSL 1.1.1t 7 Feb 2023
debug1: Reading configuration data /packages/openssh-9.3p1-1/.settings/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to git.haiku-os.org [206.189.242.242] port 22.
debug1: Connection established.
debug1: identity file /boot/home/config/settings/ssh/id_rsa type 0
debug1: identity file /boot/home/config/settings/ssh/id_rsa-cert type -1
debug1: identity file /boot/home/config/settings/ssh/id_ecdsa type -1
debug1: identity file /boot/home/config/settings/ssh/id_ecdsa-cert type -1
debug1: identity file /boot/home/config/settings/ssh/id_ecdsa_sk type -1
debug1: identity file /boot/home/config/settings/ssh/id_ecdsa_sk-cert type -1
debug1: identity file /boot/home/config/settings/ssh/id_ed25519 type 3
debug1: identity file /boot/home/config/settings/ssh/id_ed25519-cert type -1
debug1: identity file /boot/home/config/settings/ssh/id_ed25519_sk type -1
debug1: identity file /boot/home/config/settings/ssh/id_ed25519_sk-cert type -1
debug1: identity file /boot/home/config/settings/ssh/id_xmss type -1
debug1: identity file /boot/home/config/settings/ssh/id_xmss-cert type -1
debug1: identity file /boot/home/config/settings/ssh/id_dsa type -1
debug1: identity file /boot/home/config/settings/ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.3
debug1: Remote protocol version 2.0, remote software version GerritCodeReview_3.7.3 (APACHE-SSHD-2.9.2)
debug1: compat_banner: no match: GerritCodeReview_3.7.3 (APACHE-SSHD-2.9.2)
debug1: Authenticating to git.haiku-os.org:22 as 'kenz-gelsoft'
debug1: load_hostkeys: fopen /boot/home/config/settings/ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /packages/openssh-9.3p1-1/.settings/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /packages/openssh-9.3p1-1/.settings/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Go37CBc4QorVvZ5fVncu2J78c1ve/BGqklYwoNMa9mQ
debug1: load_hostkeys: fopen /boot/home/config/settings/ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /packages/openssh-9.3p1-1/.settings/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /packages/openssh-9.3p1-1/.settings/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'git.haiku-os.org' is known and matches the ED25519 host key.
debug1: Found key in /boot/home/config/settings/ssh/known_hosts:4
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /boot/home/config/settings/ssh/id_rsa RSA SHA256:NGtotQrjfDpa7GrJIHd+R1kZJuEsPcaCtITKPNNICu4
debug1: Will attempt key: /boot/home/config/settings/ssh/id_ecdsa
debug1: Will attempt key: /boot/home/config/settings/ssh/id_ecdsa_sk
debug1: Will attempt key: /boot/home/config/settings/ssh/id_ed25519 ED25519 SHA256:LtXw2/zvaOm7YBMOrJ5jc+qagO0kQ8ba0iWpuILtbsI
debug1: Will attempt key: /boot/home/config/settings/ssh/id_ed25519_sk
debug1: Will attempt key: /boot/home/config/settings/ssh/id_xmss
debug1: Will attempt key: /boot/home/config/settings/ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /boot/home/config/settings/ssh/id_rsa RSA SHA256:NGtotQrjfDpa7GrJIHd+R1kZJuEsPcaCtITKPNNICu4
debug1: Authentications that can continue: publickey
debug1: Trying private key: /boot/home/config/settings/ssh/id_ecdsa
debug1: Trying private key: /boot/home/config/settings/ssh/id_ecdsa_sk
debug1: Offering public key: /boot/home/config/settings/ssh/id_ed25519 ED25519 SHA256:LtXw2/zvaOm7YBMOrJ5jc+qagO0kQ8ba0iWpuILtbsI
debug1: Server accepts key: /boot/home/config/settings/ssh/id_ed25519 ED25519 SHA256:LtXw2/zvaOm7YBMOrJ5jc+qagO0kQ8ba0iWpuILtbsI
Authenticated to git.haiku-os.org ([206.189.242.242]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: Sending subsystem: sftp
subsystem request failed on channel 0
scp: Connection closed
~/src>
You need to add the -O option according to ssh - subsystem request failed on channel 0 scp: Connection closed - Macbook - Stack Overflow
We should update the page to mention that.
as far as Librewolf goes, the screenshot below shows how far I got. Not sure where the error is but I did figure out that you need python3.9 for the script to even start.
Although I’m working on a debugger usable with firefox now, I targeted the ESR 102 branch of firefox.
Newer firefox (variants) may require relatively new dependencies which not available on Haikuports.
As the ESR version 115 will be released on this summer, then I will consider rebasing my
WIP changes on it. If it will be required I may help upgrading dependencies.
12 posts were merged into an existing topic: Port PaleMoon to Haiku?
In this topic, uenz is trying to port Firefox. And they seem to know what they are doing, I assume it’s not their first time working with the Firefox codebase. Why do people think it is a good idea to list other browsers that can be ported? If you want to work on porting one of them, why not start your own forum topic?
I don’t remember exactly where I saw the news, but I think there has been some pull request recently to get rid of libxul in the Firefox codebase completely.
“official” from the Haiku or HaikuPorts team, and while retaining the PaleMoon name, yes.
If the PaleMoon team decides to make an official release in their own way, they certainly can do so.
Not really, the goal of PaleMoon is to somehow keep alive an older version of Firefox. The code for current Firefox has probably been fully rewritten 3 times since then. And it’s not exactly a friendly fork.
Probably this blogpost: XUL Layout is gone | Words
However, I think libxul contains much more than just the XUL layout engine, in fact it is pretty much all of the Firefox web engine internals, if I understand correctly? The naming is a bit confusing if that’s the case…
I’m searching for this, I just found this HN post about why libxul is current form
For all the non-developers in this thread who OT-ed this thread :
please open another thread AS some of us – for example me (!) – would like to read about THIS OFFERED Firefox ESR porting effort progress.
Not your dreams - in this case. Period.
In case names popping thread of this Firefox browser I had defensed the imaginarious behaviour - from the “adults” – but HERE it is a real deal.
Firefox ESR is just enough for us, down-to-earth people, whom this proposal is quite good : so; thanks to continue discuss elsewhere …
to be able to read about the progress (if/when anything comes).
It is very dedpressing when seeing number of new posts, click on it … and finally reading only wishful bla-bla against the awaited news :((…
In addition to this, all the people wanting their bespoke firefox forks ported will see benefits from this code as surely some of the patchset will apply to their own browsers. But for now, we have to focus on our main target, which is ESR.