This is not our port’s problem. It occurs with users of other operating systems as well. Consistently awful media playback · Issue #3591 · BrowserWorks/Waterfox · GitHub
Does Icedove open Thunderbird mail extensions (old ones 2003)?
Somewhere I have an old backup of Thunderbird but cannot open the emails on that CD!
Added a platform-specific implementation for handling command-line arguments in Iceweasel using Haiku’s ports. This allows secondary processes to pass parameters to the main instance, enabling features like opening urls and files from Tracker into new tabs.
Could there be something wrong with RAM usage on this port? When running it takes up a sizable chunk of RAM, which is to be expected, but once it’s closed a lot of the RAM used doesn’t seem to free up and ProcessController lists it as cached RAM… I think?
This is the About screen with no other apps open showing 5 gigs of RAM are in use after having used Iceweasel for about 2 hours or so, browsing, watching videos and stuff like that. In that situation the system should be using about 1 gig realistically, probably even less.
This is what ProcessController looks like (there’s more RAM in use because this screenshot was taken later)
Maybe it’s unrelated to Iceweasel, maybe it’s a system bug but I thought I’d ask here since I only notice this after having used the browser.
I also saw this. I generally try to reboot after some days, but, for those who have not 16gb of ram or higher, it can be troublesome.
This is not indicative of a problem with that particular application, but of memory leaks in the kernel or a kernel module. I have been observing leaks for a long time. They are especially noticeable when building all Firefox forks. I barely have 32 GB for a build and after the build is finished, memory remains occupied even though all compiler processes have already finished.
EDIT: This began to be observed, if I am not mistaken after the recent change of system allocator. The question requires more detailed investigation. There were ideas that RAMFS is to blame but it is not. @waddlesplash any thoughts on this?
Oh, I see, thank you for the explanation
I haven’t managed to reproduce it. @diver reported something similar, but I’ve solved his problem a few weeks back, and he hasn’t managed to reproduce any other as far as I know. I haven’t seen this behavior myself.
You’ll have to try and track down where the memory is going, that’s the first step in trying to solve this. Does it happen when building anything, or just Firefox? Is it occupied in pages, or the kernel memory allocator, or in something else? Does it happen in VMs or only on bare metal?
If you can narrow it down or get a reliable and quick reproducer that happens in a VM, or at least on more than one machine, I can see about trying again to reproduce it here. Or if you manage to determine when it started I can investigate based on that.
It’s reproducible in a very simple way:
- enable iceweasel recipe build (remove !)
- start the recipe build with haikuporter
- when memory consumption grows noticeably (after about 10 minutes) interrupt the build with Ctr+C (or wait for the full build of the package)
- After interruption memory will not be freed
I haven’t tried the Iceweasel build yet, but I have tried restarting Iceweasel repeatedly, with nothing open but the homepage. Here’s a comparison between runs:
So the overall memory used went up by about 6 MB; however there’s nowhere this memory apparently went. The kernel increased by 0.57 MB, a few other applications gained a bit, but not anywhere near 6 MB.
Opening and closing Iceweasel again, the memory usage again went up by 6 MB. So indeed something seems to be getting leaked here.
Right now we don’t have any accounting for RAMFS memory usage, that should really be fixed. However I unmounted the RAMFS device and it didn’t give me any warnings and no memory was freed (however depending on cache references, maybe none would be? So I need to check more here before I rule this out.)
It seems to me that the big leaks occur when the rust compiler is worked. I encounter this when building iceweasel, recently x512 mentioned rust related leaks when building nvk
Memory leak became a feature in rust, compilation problem in 32 bits, it’s another memory leak in rust!
I also get this app_server crash quite often. Seems related to cursor/drag bitmap reference count mismatch.
Iceweasel is crashing when uploading on Google Drive, click on add (no drag and drop) and suddenly it crash, repeated multiple times. Same with Floorp
version: Latest Nightly Hrev58852
- Updated the entire suite of applications to their latest versions: Iceweasel 138.0.1, LibreWolf 138.0.1, Waterfox 6.5.7, Floorp 11.26.0, and Icedove 138.0
- Added launchers to enable opening files and links from other applications (can be configured via FileTypes)
- Added a Tracker add-on for the Icedove email client, which allows you to send selected files as attachments in a new email
Nice.
Tyring Icedove and the problem with some special chars (by example, ‘@’ as Alt-gr + 0 on French KB) not available from keyboard input is also present as Iceweasel.
Any known workaround ?
In the worst case scenario you can use the Keymap application, click on the @ key and then copy /paste from the clipboard to Icedove:)
yes, i use copy/paste via clipboard --copy=@ …
On Haiku, any way to do as Windows with alt + xxx ?
(Insert ASCII or Unicode Latin-based symbols and characters - Microsoft Support)