Element-R: Desktop app crashes when event search is enabled

[richvdh]

If I enable client-side event search, the desktop app crashes within a few seconds.

[t3chguy]

@richvdh logs please

[richvdh]

yes yes, hold your horses.

[richvdh]

Stacktrace is

(gdb) bt
#0  0x000055b355f1b58f in partition_alloc::internal::DiscardSystemPagesInternal(unsigned long, unsigned long) (address=<optimised out>, length=<optimised out>) at ../../base/allocator/partition_allocator/page_allocator_internals_posix.h:420
#1  partition_alloc::DiscardSystemPages(unsigned long, unsigned long) (address=<optimised out>, length=<optimised out>) at ../../base/allocator/partition_allocator/page_allocator.cc:352
#2  0x000055b355f226e2 in partition_alloc::internal::PartitionPurgeSlotSpan(partition_alloc::PartitionRoot*, partition_alloc::internal::SlotSpanMetadata*, bool)
    (root=0x55b35dd3dc40 <allocator_shim::ConfigurePartitions(partition_alloc::internal::base::StrongAlias<allocator_shim::EnableBrpTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::EnableMemoryTaggingTag, bool>, partition_alloc::TagViolationReportingMode, partition_alloc::internal::base::StrongAlias<allocator_shim::SplitMainPartitionTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::UseDedicatedAlignedPartitionTag, bool>, unsigned long, allocator_shim::BucketDistribution)::new_main_allocator>, slot_span=0x2da8054016c0, accounting_only=false)
    at ../../base/allocator/partition_allocator/partition_root.cc:573
#3  0x000055b355f2177c in partition_alloc::internal::PartitionPurgeBucket(partition_alloc::PartitionRoot*, partition_alloc::internal::PartitionBucket*)
    (root=0x55b35dd3dc40 <allocator_shim::ConfigurePartitions(partition_alloc::internal::base::StrongAlias<allocator_shim::EnableBrpTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::EnableMemoryTaggingTag, bool>, partition_alloc::TagViolationReportingMode, partition_alloc::internal::base::StrongAlias<allocator_shim::SplitMainPartitionTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::UseDedicatedAlignedPartitionTag, bool>, unsigned long, allocator_shim::BucketDistribution)::new_main_allocator>, bucket=0x55b35dd3e188 <allocator_shim::ConfigurePartitions(partition_alloc::internal::base::StrongAlias<allocator_shim::EnableBrpTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::EnableMemoryTaggingTag, bool>, partition_alloc::TagViolationReportingMode, partition_alloc::internal::base::StrongAlias<allocator_shim::SplitMainPartitionTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::UseDedicatedAlignedPartitionTag, bool>, unsigned long, allocator_shim::BucketDistribution)::new_main_allocator+1352>) at ../../base/allocator/partition_allocator/partition_root.cc:668
#4  partition_alloc::PartitionRoot::PurgeMemory(int)
    (this=0x55b35dd3dc40 <allocator_shim::ConfigurePartitions(partition_alloc::internal::base::StrongAlias<allocator_shim::EnableBrpTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::EnableMemoryTaggingTag, bool>, partition_alloc::TagViolationReportingMode, partition_alloc::internal::base::StrongAlias<allocator_shim::SplitMainPartitionTag, bool>, partition_alloc::internal::base::StrongAlias<allocator_shim::UseDedicatedAlignedPartitionTag, bool>, unsigned long, allocator_shim::BucketDistribution)::new_main_allocator>, flags=3) at ../../base/allocator/partition_allocator/partition_root.cc:1376
#5  0x000055b355f1b264 in partition_alloc::MemoryReclaimer::Reclaim(int) (this=0x55b35dd3c008 <partition_alloc::MemoryReclaimer::Instance()::instance>, flags=3) at ../../base/allocator/partition_allocator/memory_reclaimer.cc:89
#6  0x000055b3594e5118 in base::allocator::(anonymous namespace)::RunMemoryReclaimer(scoped_refptr<base::SequencedTaskRunner>) (task_runner=...) at ../../base/allocator/partition_alloc_support.cc:236
#7  0x000055b359475fad in base::OnceCallback<void ()>::Run() && (this=0x2da80187a000) at ../../base/functional/callback.h:152
#8  base::TaskAnnotator::RunTaskImpl(base::PendingTask&) (this=<optimised out>, pending_task=...) at ../../base/task/common/task_annotator.cc:201
#9  0x000055b3594934d4 in base::TaskAnnotator::RunTask<base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*)::$_0>(perfetto::StaticString, base::PendingTask&, base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*)::$_0&&)
    (this=0x1278003041d8, pending_task=..., event_name=..., args=<optimised out>) at ../../base/task/common/task_annotator.h:89
#10 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*) (this=0x127800304000, continuation_lazy_now=0x7ffc499797f0) at ../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:480
#11 0x000055b359493a95 in non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() () at ../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:345
#12 0x000055b3594f2c1b in base::MessagePumpGlib::HandleDispatch() (this=0x12780023afc0) at ../../base/message_loop/message_pump_glib.cc:646
#13 base::(anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) (source=<optimised out>, unused_func=<optimised out>, unused_data=<optimised out>) at ../../base/message_loop/message_pump_glib.cc:274
#14 0x00007f589a31bd3b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f589a371258 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007f589a3193e3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x000055b3594f2214 in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) (this=0x12780023afc0, delegate=<optimised out>) at ../../base/message_loop/message_pump_glib.cc:680
#18 0x000055b359494150 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) (this=0x127800304000, application_tasks_allowed=true, timeout=...) at ../../base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:645
#19 0x000055b3594555d1 in base::RunLoop::Run(base::Location const&) (this=0x2da801347640, location=<optimised out>) at ../../base/run_loop.cc:134
#20 0x000055b35848537f in content::BrowserMainLoop::RunMainMessageLoop() (this=<optimised out>) at ../../content/browser/browser_main_loop.cc:1071
#21 0x000055b358487252 in content::BrowserMainRunnerImpl::Run() (this=0x2da800020660) at ../../content/browser/browser_main_runner_impl.cc:158
#22 0x000055b358482839 in content::BrowserMain(content::MainFunctionParams) (parameters=...) at ../../content/browser/browser_main.cc:34
#23 0x000055b356033294 in content::RunBrowserProcessMain(content::MainFunctionParams, content::ContentMainDelegate*) (main_function_params=..., delegate=0x7ffc4997a230) at ../../content/app/content_main_runner_impl.cc:708
#24 0x000055b356034b6e in content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams, bool) (this=0x1278002aa290, main_params=..., start_minimal_browser=<optimised out>) at ../../content/app/content_main_runner_impl.cc:1292
#25 0x000055b35603494f in content::ContentMainRunnerImpl::Run() (this=0x1278002aa290) at ../../content/app/content_main_runner_impl.cc:1142
#26 0x000055b3560321be in content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*) (params=..., content_main_runner=0x1278002aa290) at ../../content/app/content_main.cc:330
#27 0x000055b3560322c6 in content::ContentMain(content::ContentMainParams) (params=...) at ../../content/app/content_main.cc:347
#28 0x000055b355d150d9 in main(int, char**) (argc=<optimised out>, argv=0x7ffc4997a428) at ../../electron/shell/app/electron_main_linux.cc:45

... making this the same thing as #691

[t3chguy]

Duplicate of #691

[t3chguy]

Yay not a new ED-R issue :P

[richvdh]

It's much, much worse with ER.

[ara4n]

I've never seen this (pre-ER) on macOS, fwiw, despite hammering the hell out of seshat. sounds like it might be libc-specific?

[richvdh]

I've never seen this (pre-ER) on macOS, fwiw, despite hammering the hell out of seshat. sounds like it might be libc-specific?

I've no doubt it is. Still if we've somehow managed to make it much worse on Linux, that seems like a blocker for release.

(In the meantime, if you're keen to try ER on desktop, you can use a custom config.json and set "features": { "feature_rust_crypto": true }. )

[ara4n]

/me leaps on it (and hopes it won't DoS everything with key reqs)

[richvdh]

/me leaps on it (and hopes it won't DoS everything with key reqs)

I mean it will, but as far as we can tell, so did legacy crypto. I suggest you choose a moment when you can afford to wait a while for your other devices to catch up with their to-device messages.

[richvdh]

We've decided that, since this only affects Linux users, and it was a previously-existing issue, not to block rollout of element R on it.

As such, we might as well close it as a duplicate of #691.