Password page empty and crashes after sync

[dairefagan]

Description

Opening brave://settings/passwords on a new install after completing sync crashes the tab and no passwords are displayed, although the passwords were synced as they are autofilled on websites as normal and I can also see this in brave://sync-internals/.

Steps to Reproduce

1. Install Brave on Ubuntu 20.04 using the official brave repo
2. Sync Brave to your existing chain with more than 1000 passwords
3. Observe the passwords page of settings crashes and displays no passwords

Actual result:

After syncing a new install the passwords page crashes.

Expected result:

Brave syncs and displays passwords as normal in the passwords page.

Reproduces how often:

Always and easily.

Brave version (info found on brave://version)

Brave | 1.28.106 Chromium: 92.0.4515.159 (Official Build) (64-bit)
Revision | 0185b8a19c88c5dfd3e6c0da6686d799e9bc3b52-refs/branch-heads/4515@{#2052}
OS | Linux

Version/Channel Information:

• Can you reproduce this issue with the current release? Yes
• Can you reproduce this issue with the beta channel? Unknown
• Can you reproduce this issue with the dev channel? Unknown
• Can you reproduce this issue with the nightly channel? Unknown

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? No, NA
• Does the issue resolve itself when disabling Brave Rewards? No
• Is the issue reproducible on the latest version of Chrome? Unknown

Miscellaneous Information:

I tried fixing this by first removing Login data, then reinstalling, then reinstalling with password sync off on all devices and trying a manual export/import. After completing the manual export from an existing install on another device and then importing to the new device the passwords did at least display properly - until Brave was relaunched and I observe the same issue again.

[rebron]

@dairefagan When you get a chance, can you go to brave://crashes send the report and paste the crash id here.
cc: @jsecretan

[dairefagan]

Sure, here are two. The first occurred after I searched settings for passwords. On clicking passwords it froze without progressing the page, still displaying the Autofill menu. The other was when instead navigating to the passwords menu, which I was able to access, but it was empty and there the page froze and become unresponsive.

a78c0700-eb58-d306-0000-000000000000
ab8c0700-eb58-d306-0000-000000000000

Just to clarify Brave itself has not crashed and closed, just the tab freezes.

Sometimes the freeze happens before I can even see the empty passwords page:

Other times I at least make it that far:

Also, when duplicating just now I was once able to successfully display my passwords but this is the only time this has happened since installing on this new system, and closing Brave and trying again resulted in the same issue.

Also I notice in sync intervals I have 2195 passwords, which is double the amount I know I have from manually exporting from my other system. I expect this is to do with syncing and importing when I tried to fix this issue, even though I removed the logins file before importing, and that I should reset these some how that this will not occur?

[jsecretan]

@AlexeyBarabash could you please check those crash report ids?

[AlexeyBarabash]

The crashes seems were done manually to generate a dump on freezing with url like brave://inducebrowsercrashforrealz/ :

https://brave.sp.backtrace.io/p/brave/debug?filters=(_rxid%3Da78c0700-eb58-d306-0000-000000000000)&debug=(%2225a7ffb%22,0,0)

[ 00 ] blink::internal::CrashIntentionally()
[ 01 ] blink::HandleChromeDebugURL(GURL const&)
[ 02 ] blink::LocalFrame::HandleRendererDebugURL(blink::KURL const&)
[ 03 ] blink::mojom::blink::LocalFrameStubDispatch::Accept(blink::mojom::blink::LocalFrame*, mojo::Message*)
[ 04 ] mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*)
[ 05 ] mojo::MessageDispatcher::Accept(mojo::Message*)
[ 06 ] mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*)
[ 07 ] IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread(mojo::Message)
[ 08 ] base::internal::Invoker<base::internal::BindState<void (mojo::(anonymous namespace)::ThreadSafeInterfaceEndpointClientProxy::*)(mojo::Message), scoped_refptr<mojo::(anonymous namespace)::ThreadSafeInterfaceEndpointClientProxy>, mojo::Message>, void ()>::RunOnce(base::internal::BindStateBase*)
[ 09 ] base::TaskAnnotator::RunTask(char const*, base::PendingTask*)
[ 10 ] base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
[ 11 ] non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
[ 12 ] base::MessagePumpDefault::Run(base::MessagePump::Delegate*)
[ 13 ] base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta)
[ 14 ] base::RunLoop::Run(base::Location const&)
[ 15 ] content::RendererMain(content::MainFunctionParams const&)
[ 16 ] content::ContentMainRunnerImpl::Run(bool)
[ 17 ] content::ContentMain(content::ContentMainParams const&)
[ 18 ] ChromeMain
[ 19 ] __cpu_indicator_init
[ 20 ] 0x555873325080
[ 21 ] __libc_start_main
[ 22 ] wl_data_device_manager_destroy(wl_data_device_manager*) (.3d72a8c3e63e95bd16e6c637c572b060)
[ 23 ] __cpu_indicator_init
[ 24 ] 0x555873325080
[ 25 ] 0x555873325080
[ 26 ] _start

https://brave.sp.backtrace.io/p/brave/debug?time=month&filters=(_rxid%3Dab8c0700-eb58-d306-0000-000000000000)&debug=(%2225a7ffd%22,0,0)

[ 00 ] blink::internal::CrashIntentionally()
[ 01 ] blink::HandleChromeDebugURL(GURL const&)
[ 02 ] blink::LocalFrame::HandleRendererDebugURL(blink::KURL const&)
[ 03 ] blink::mojom::blink::LocalFrameStubDispatch::Accept(blink::mojom::blink::LocalFrame*, mojo::Message*)
[ 04 ] mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*)
[ 05 ] mojo::MessageDispatcher::Accept(mojo::Message*)
[ 06 ] mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*)
[ 07 ] IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread(mojo::Message)
[ 08 ] base::internal::Invoker<base::internal::BindState<void (mojo::(anonymous namespace)::ThreadSafeInterfaceEndpointClientProxy::*)(mojo::Message), scoped_refptr<mojo::(anonymous namespace)::ThreadSafeInterfaceEndpointClientProxy>, mojo::Message>, void ()>::RunOnce(base::internal::BindStateBase*)
[ 09 ] base::TaskAnnotator::RunTask(char const*, base::PendingTask*)
[ 10 ] base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
[ 11 ] non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
[ 12 ] base::MessagePumpDefault::Run(base::MessagePump::Delegate*)
[ 13 ] base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta)
[ 14 ] base::RunLoop::Run(base::Location const&)
[ 15 ] content::RendererMain(content::MainFunctionParams const&)
[ 16 ] content::ContentMainRunnerImpl::Run(bool)
[ 17 ] content::ContentMain(content::ContentMainParams const&)
[ 18 ] ChromeMain
[ 19 ] __cpu_indicator_init
[ 20 ] 0x555873325080
[ 21 ] __libc_start_main
[ 22 ] wl_data_device_manager_destroy(wl_data_device_manager*) (.3d72a8c3e63e95bd16e6c637c572b060)
[ 23 ] __cpu_indicator_init
[ 24 ] 0x555873325080
[ 25 ] 0x555873325080
[ 26 ] _start

In both these dumps other threads are in wait state without extra symbols, so it is hard to say was that a deadlock and which parts were involved.

I will try to reproduce that, thanks for the report.

[AlexeyBarabash]

I could not reproduce the issue.
Used 1100 passwords file to import.

echo name,url,username,password                                               >  ExportedPasswords.csv
for i in {1..1100}
do
   echo keepass.info,https://keepass.info/help/kb/testform.html,Username$i,Password$i             >> ExportedPasswords.csv
done

Two not good things happened:

1. After the import it took long time for brave://settings/passwords page to show the imported passwords, more than a minute. Even when the device had not sync enabled.

2. The imported passwords were propagated to other device in chain - and while that was happening, the page brave://settings/passwords was not responsive for several minutes.

So the process of adding lot of bookmarks through import or sync is time consuming and UI page brave://settings/passwords need time to show all the passwords.

And the question while crash had happened - is still opened.

Brave	1.31.9 Chromium: 93.0.4577.58 (Developer Build) (64-bit)
Revision	c4410ece044414ea42fa4ba328d08195e818a99c-refs/branch-heads/4577@{#1076}
OS	Linux

The passwords file attached:
ExportedPasswords.csv

[AlexeyBarabash]

Import of 11000 of passwords made the brave://settings/passwords never to display them all and the page brave://sync-internals/ went to a weird state:

It seems there is some limit of passwords number when such big value affects on everything.

[AlexeyBarabash]

After relaunch browser and click on the empty area in settings, I also could get this:

[AlexeyBarabash]

And somehow I could put one of the devices into BackedOff updates state , with CONFLICT reason:

This is not expected and may cause more troubles. I could make it by importing 11000 of passwords into each device in the chain.

[iefremov]

should we close if there is nothing actionable? @jsecretan @AlexeyBarabash ?

[AlexeyBarabash]

Closing as we can't do much when the page gets killed because unresponsive.

[dairefagan]

This issue is ongoing, I can view passwords fine on Android but Linux either does not display or freezes Brave.

…

On Mon 9 Jan 2023, 17:38 AlexeyBarabash, ***@***.***> wrote: Closed #17605 <#17605> as completed. — Reply to this email directly, view it on GitHub <#17605 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7PTBU5C5UCWOXF3WBFOKLWRREJ5ANCNFSM5CQWCFHQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dairefagan]

i upgraded Ubuntu to 22.04.1 a few days ago and this seems resolved on Version 1.47.186 Chromium: 109.0.5414.119 (Official Build) (64-bit).