[Flatpak] Crash Shortly After Launch

[ThisNekoGuy]

Description

• https://github.com/flathub/com.brave.Browser/issues/658#issuecomment-2430621297

I noticed that OS/Linux/Flatpak was a label for issues over here, so I figured reporting this crash (over from the Flatpak repo) might help with getting this issue the proper visibility. (Do still feel free to look over the original though)

It's not entirely clear what specifically is causing the issue, but I did notice that it began (for me - I can't say for the other users) after enabling Brave ads/rewards. Initially, the crash only happened after a few minutes - long enough for me to do some reading about the Brave token system and start to sign up for the Brave wallet... to then be interrupted by a momentary freeze while I was interacting with the form and then experience the crash. After that, each attempt to launch the browser was met with a crash within probably 60 seconds or less and, in that time, my process viewer reveals that Brave very quickly balloons in RAM usage and then seems to terminate after around 10GBs or so. (For context, I have 32GBs available, so it isn't that my system ran out of RAM.)

Prior to what I mentioned about the Brave ads/rewards, the only thing I really did worthy of mention was open 13 tabs and import some filterlists (though I'm not at all aware of how relevant that is).

Steps to reproduce

1. Install Brave via flatpak (I've had Brave installed for a while but haven't used it in a long time)
2. Import filterlists (Not sure if there's an easy way for me to include which ones here if the overall list is somewhat large)
3. Opt-in to the Brave ad system in a fresh/home tab
4. Wait for Brave to implode? (The crash occurs both on the default of X11 and Wayland modes)

(Given that I only have one desktop, I can't reproduce it on another one, but this was what I did.)

Actual result

When running from the terminal:

/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=brave --file-forwarding com.brave.Browser --ozone-platform-hint=auto --enable-features=UseOzonePlatform,WaylandWindowDecorations --password-store=basic

[2:2:1022/205227.657879:ERROR:CONSOLE(2185)] "[Settings] Appearance Page cannot find use default theme button template", source: chrome://settings/settings.js (2185)
tracing_subscriber - init success
[1022/205253.963518:ERROR:scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted (1)

(Ignore --password-store=basic, I just had that there because Brave was looking for KWallet on my system despite that I keep it turned off.)

Expected result

Ideally, Brave's RAM usage shouldn't aggressively increase and the browser shouldn't be crashing.

Reproduces how often

Easily reproduced

Brave version (brave://version info)

Brave   1.71.114 Chromium: 130.0.6723.58 (Official Build) unknown (64-bit) 
Revision    89c4031c685a4296315a6f421f46275f0b72dd55
OS  Linux
JavaScript  V8 13.0.245.16
User Agent  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

Desktop Info:

[!NOTE] OS: Gentoo Linux 2.15 (Completely LLVM18 built & w/ glibc) Kernel: 6.10.9 DE: KDE Plasma 6.1.5 Desktop Session: Wayland RAM: 32GBs @ 3600 MHz

Channel information

• [x] release (stable)
• [ ] beta
• [ ] nightly

Reproducibility

• [ ] with Brave Shields disabled
• [x] with Brave Rewards disabled (Turning it back off doesn't resolve the issue)
• [ ] in the latest version of Chrome

Miscellaneous information

[!NOTE] EDIT: Using flatseal, I was able to enable ptrace support for Brave:

Screenshot:


then subsequently (and temporarily), do: sudo sh -c 'echo 0 > /proc/sys/kernel/yama/ptrace_scope' which lets Brave's ptrace function, revealing this about the crashes:

[1023/102917.347511:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1023/102917.347659:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1023/102917.347774:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1023/102917.359870:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1023/102917.360098:ERROR:elf_dynamic_array_reader.h(64)] tag not found

This let the Brave crash folder (finally) get used and the brave://crashes page tells me that the Uploaded Crash Report ID is be160000-9344-cf0c-0000-000000000000.

[bsclifton]

cc: @wknapik

[wknapik]

@ThisNekoGuy can you please enable crash reporting and share crash ids from brave://crashes?

[ThisNekoGuy]

@ThisNekoGuy can you please enable crash reporting and share crash ids from brave://crashes?

I actually already did have crash reporting enabled...

Also, here's a screenshot of brave://crashes:

[!NOTE] (Like I mentioned in the original post here though, this menu only gets populated if the Miscellaneous information section was followed).

[wknapik]

@ThisNekoGuy can you please click Send now on the top 3 crashes and share the IDs for all 6 as a text comment here? Typing them out manually from the screenshot would be a pain.

[ThisNekoGuy]

1. be160000-9344-cf0c-0000-000000000000
2. 911f0000-9344-cf0c-0000-000000000000
3. f6280000-9344-cf0c-0000-000000000000
4. a06f1300-9344-cf0c-0000-000000000000
5. af6f1300-9344-cf0c-0000-000000000000
6. c16f1300-9344-cf0c-0000-000000000000

[iefremov]

@ThisNekoGuy many thanks for the report. Can you share what's on your brave://settings/shields/filters ?

[iefremov]

cc @ShivanKaul @antonok-edm

[ 00 ] __rust_alloc_error_handler ( remap_alloc.cc:157 )
[ 01 ] alloc::alloc::handle_alloc_error::rt_error ( alloc.rs:384 )
[ 02 ] alloc::alloc::handle_alloc_error ( alloc.rs:390 )
[ 03 ] alloc::raw_vec::handle_error ( raw_vec.rs:789 )
[ 04 ] alloc::raw_vec::RawVecInner<A>::reserve::do_reserve_and_handle ( raw_vec.rs:555 )
[ 05 ] adblock::lists::FilterSet::add_filter_list ( raw_vec.rs:560 )
[ 06 ] adblock_cxx::filter_set::FilterSet::add_filter_list_with_permissions ( filter_set.rs:35 )
[ 07 ] adblock_cxx::filter_set::FilterSet::add_filter_list::h045e8a02798c236b ( filter_set.rs:26 )
[ 08 ] adblock_cxx::ffi::_::__FilterSet__add_filter_list::__FilterSet__add_filter_list::h0d7e2318017ff972 ( lib.rs:21 )
[ 09 ] adblock_cxx::ffi::_::__FilterSet__add_filter_list::_$u7b$$u7b$closure$u7d$$u7d$::h39b8c37cc762c05d ( lib.rs:18 )
[ 10 ] cxx::unwind::prevent_unwind::hffe2a74b095a10bb ( unwind.rs:23 )
[ 11 ] adblock_cxx::ffi::_::__FilterSet__add_filter_list ( lib.rs:23 )
[ 12 ] adblock::FilterSet::add_filter_list(std::__Cr::vector<unsigned char, std::__Cr::allocator<unsigned char>> const&) ( lib.rs.cc:1228 )
[ 13 ] brave_shields::(anonymous namespace)::AddDATBufferToFilterSet(base::OnceCallback<void (adblock::FilterListMetadata const&)>, std::__Cr::vector<unsigned char, std::__Cr::allocator<unsigned char>>, rust::cxxbridge1::Box<adblock::FilterSet>*) ( ad_block_subscription_filters_provider.cc:28 )
[ 14 ] base::internal::Invoker<base::internal::FunctorTraits<void (*&&)(base::OnceCallback<void (adblock::FilterListMetadata const&)>, std::__Cr::vector<unsigned char, std::__Cr::allocator<unsigned char>>, rust::cxxbridge1::Box<adblock::FilterSet>*), base::OnceCallback<void (adblock::FilterListMetadata const&)>&&, std::__Cr::vector<unsigned char, std::__Cr::allocator<unsigned char>>&&>, base::internal::BindState<false, true, false, void (*)(base::OnceCallback<void (adblock::FilterListMetadata const&)>, std::__Cr::vector<unsigned char, std::__Cr::allocator<unsigned char>>, rust::cxxbridge1::Box<adblock::FilterSet>*), base::OnceCallback<void (adblock::FilterListMetadata const&)>, std::__Cr::vector<unsigned char, std::__Cr::allocator<unsigned char>>>, void (rust::cxxbridge1::Box<adblock::FilterSet>*)>::RunOnce(base::internal::BindStateBase*, rust::cxxbridge1::Box<adblock::FilterSet>*) ( bind_internal.h:671 )
[ 15 ] brave_shields::RunAllResults(std::__Cr::vector<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>, std::__Cr::allocator<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>>>, rust::cxxbridge1::Box<adblock::FilterSet>*) ( callback.h:156 )
[ 16 ] base::internal::Invoker<base::internal::FunctorTraits<void (*&&)(std::__Cr::vector<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>, std::__Cr::allocator<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>>>, rust::cxxbridge1::Box<adblock::FilterSet>*), std::__Cr::vector<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>, std::__Cr::allocator<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>>>&&>, base::internal::BindState<false, true, false, void (*)(std::__Cr::vector<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>, std::__Cr::allocator<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>>>, rust::cxxbridge1::Box<adblock::FilterSet>*), std::__Cr::vector<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>, std::__Cr::allocator<base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>>>>, void (rust::cxxbridge1::Box<adblock::FilterSet>*)>::RunOnce(base::internal::BindStateBase*, rust::cxxbridge1::Box<adblock::FilterSet>*) ( bind_internal.h:671 )
[ 17 ] base::internal::Invoker<base::internal::FunctorTraits<brave_shields::AdBlockService::SourceProviderObserver::OnFilterSetCallbackLoaded(base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>)::$_0&&, base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>&&>, base::internal::BindState<false, false, false, brave_shields::AdBlockService::SourceProviderObserver::OnFilterSetCallbackLoaded(base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>)::$_0, base::OnceCallback<void (rust::cxxbridge1::Box<adblock::FilterSet>*)>>, std::__Cr::unique_ptr<rust::cxxbridge1::Box<adblock::FilterSet>, std::__Cr::default_delete<rust::cxxbridge1::Box<adblock::FilterSet>>> ()>::RunOnce(base::internal::BindStateBase*) ( callback.h:156 )
[ 18 ] void base::internal::ReturnAsParamAdapter<std::__Cr::unique_ptr<rust::cxxbridge1::Box<adblock::FilterSet>, std::__Cr::default_delete<rust::cxxbridge1::Box<adblock::FilterSet>>>>(base::OnceCallback<std::__Cr::unique_ptr<rust::cxxbridge1::Box<adblock::FilterSet>, std::__Cr::default_delete<rust::cxxbridge1::Box<adblock::FilterSet>>> ()>, std::__Cr::unique_ptr<std::__Cr::unique_ptr<rust::cxxbridge1::Box<adblock::FilterSet>, std::__Cr::default_delete<rust::cxxbridge1::Box<adblock::FilterSet>>>, std::__Cr::default_delete<std::__Cr::unique_ptr<rust::cxxbridge1::Box<adblock::FilterSet>, std::__Cr::default_delete<rust::cxxbridge1::Box<adblock::FilterSet>>>>>*) ( callback.h:156 )
[ 19 ] base::internal::PostTaskAndReplyRelay::RunTaskAndPostReply(base::internal::PostTaskAndReplyRelay) ( callback.h:156 )
[ 20 ] base::internal::Invoker<base::internal::FunctorTraits<void (*&&)(base::internal::PostTaskAndReplyRelay), base::internal::PostTaskAndReplyRelay&&>, base::internal::BindState<false, true, false, void (*)(base::internal::PostTaskAndReplyRelay), base::internal::PostTaskAndReplyRelay>, void ()>::RunOnce(base::internal::BindStateBase*) ( bind_internal.h:671 )
[ 21 ] base::internal::TaskTracker::RunSkipOnShutdown(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::internal::SequenceToken const&) ( callback.h:156 )
[ 22 ] base::internal::TaskTracker::RunAndPopNextTask(base::internal::RegisteredTaskSource) ( task_tracker.cc:693 )
[ 23 ] base::internal::WorkerThread::RunWorker() ( worker_thread.cc:493 )
[ 24 ] base::internal::WorkerThread::RunPooledWorker() ( worker_thread.cc:379 )
[ 25 ] base::internal::WorkerThread::ThreadMain() ( worker_thread.cc:359 )
[ 26 ] base::(anonymous namespace)::ThreadFunc(void*) ( platform_thread_posix.cc:101 )
[ 27 ] start_thread ( pthread_create.c:444 )
[ 28 ] __clone ( clone.S:100 )

[iefremov]

basically this is OOM while parsing filter lists, but consuming 10Gb for whatever lists doesn't sound right

[ThisNekoGuy]

@ThisNekoGuy many thanks for the report. Can you share what's on your brave://settings/shields/filters ?

Is there a file or something that logs that? The browser crashes too fast for me to be able to collect that information... (There's sort of a lot of filters)

[atuchin-m]

@ThisNekoGuy

1. copy Local State file content (~/.config/brave-browser/)
2. Format it using any JSON formatter like https://jsonviewer.stack.hu/
3. share regional_filters and list_subscriptions block

Don't share the full file because it contains sensetive information.

[ThisNekoGuy]

It was in ~/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/ (because of Flatpak), but I got it:

• subscribed-filters.txt

[atuchin-m]

You have enormous number of filters enabled, including 3rd parties. Some of 3rd party filters are likely to result in this. We are not responsible of 3rd filters correctness and speed, it's you own risk.

Note, that each extra enabled filter takes some extra memory/CPU to work (including Brave ones, but all Brave filters don't give you 10GB)

If you really need all of them, I recommend disable them one-by one. If you can't load the browser you can try just replace list_subscriptions to {} and re add some of them. Please make a backup of ~/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/ first.

cc @antonok-edm

[ThisNekoGuy]

Not to be rude, but if uBlock Origin can use 100% of these (and verifiably more without issue) I see no reason why the native filterlist mechanism in Brave shouldn't be able to. uBlock Origin under LibreWolf has no issue with this, so if adding error handling to safeguard against an OOM crash (to achieve what an extension can do) for a native feature, then I see no reason to trust any of my issues will be taken seriously in the future.

A browser extension, mind you, with these same filters (and, again, more) doesn't consume 10GBs of my RAM. Brave does. (Not to mention that I have 32GBs; I don't understand why the process runs out of memory when I have more to spare.)

1. You know adding additional filters beyond the default ones heavily implies 3rd party lists will be used, so why does Brave support it if you don't want the maintenance associated?
2. If this was never supported, then why is there not a cap on it?
3. If memory management crashes were never clear from the outset, and I'm denied support for an in-built feature, then why should I ever use Brave knowing that memory management is considered a non-issue in a Chromium-based browser of all things?

These are reasonable questions to be considering when you choose to add an in-built filter. And to be fair, uBlock Origin doesn't "officially" support massive lists either, but if a browser extension running on JavaScript can do it without crashing a browser, I see no reason why Brave can't - or rather shouldn't.

I was interested in Brave, but if this is where support for my first issue ends, I unfortunately see no reason to stay. Which is a shame because, for all of the user hype over this browser over the years, it evidently can't even be trusted to be stable. Hope none of you take it personally, but I really didn't have to waste any of my own time as an end-user to even file a report for this. I could've just gone back to pretending Brave didn't exist at the first sign of trouble: but I didn't.

[ShivanKaul]

I'm interested in understanding how/if uBO can handle this without crashing. Is it because Chromium's memory management of extensions kicks in? We shouldn't be crashing.

[ThisNekoGuy]

I'm interested in understanding how/if uBO can handle this without crashing

I can't tell you how, but I can tell you that it does avoid crashing (on FireFox-based browsers). I have 100 of my own lists over there, all of the official UBO lists, and my own filter list with over 2000 lines working just fine with the browser open 24/7. Never once had such an issue in all of my time with this configuration, nor have I ever had any noticeable/significant slowdowns.

[iefremov]

@ShivanKaul i think we just need to try to repro and debug. I don't think it's normal for the adblock engine to consume 10gb of ram (also we can easily check how much ublock consumes with the same amount of filters)