Locking up for about 30 seconds when I try to enter a web url in the address bar

Description of the issue:

In the last week or so, I start brave (fresh Windows session) and it appears to start normally. But when I try to enter an address, the entire browser locks up. I cannot resize it, select new-tab, or pull down any menus. This state lasts for 15 to 30 seconds before it functions normally. This also happens when I have not used the session for a few hours and return to it.

Steps to Reproduce (add as many as necessary): 1. 2. 3.

Please see above.

Actual Result (gifs and screenshots are welcome!):

Not applicable.

Expected result:

Not applicable.

Reproduces how often:

Every time.

Operating System and Brave Version(See the About Brave page in the main menu):

Windows 11. Brave-Browser-Beta 1.70.107 Chromium: 128.0.6613.120 (Official Build) beta (64-bit)

Additional Information:

Having this exact same issue, noticed it this week.

Windows 11, version 1.70.117 Chromium: 129.0.6668.59 (Official Build) (64-bit)

I am seeing exactly this same issue also about the last two weeks. It makes the browser unusable. Also Windows 11. Version 1.70.119 Chromium: 129.0.6668.70 (Official Build) (64-bit)

Notably the problem resolves itself when I restart my machine but will return at a random time. I assumed it could be related to how long the browser takes to make recommendations in the address bar so I disabled every type of search I can. I currently have to type in the entire address by hand without any suggestions and still this problem occurs although it does take many hours longer before it starts up again.

1 Like

I have the same issue. No extensions. I have 2 profiles enabled.
Windows 11
Version 1.70.119 Chromium: 129.0.6668.70 (Official Build) (64-bit)

I have the same issue :frowning:

Sorry for the late reply here everyone.
Can you all please try launching a Guest profile (Menu --> More tools --> Guest profile), closing the original profile window, then typing into the address bar of the Guest window and tell me if the issue persists there as well?

It still is the case in a guest window.

Can you please confirm that this behavior doesn’t occur in other browsers? Additionally, I’d be curious to know if the behavior occurs in the Beta build of the browser as well — note that downloading/installing the Beta will not overwrite or interfere with your current installation.

I’ve had the same issue - Linux Debian, brave-stable 1.70.123 and 1.70.119.
Issue went away by downgrading to 1.69.168.

I have used chromium and librewold successfully in the meantime.

I have used the beta build for a few minutes, so far so good but I am not sure how reliable that test is, as brave-beta uses a fresh new profile.

I am not an expert. Here is the end of strace before the program locks up.

pipe2([430, 441], 0)                    = 0
fcntl(441, F_DUPFD_CLOEXEC, 0)          = 443
close(441)                              = 0
sendmsg(136, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\377\1\0\24\0\7\0\0\0STRING\0\0", iov_len=20}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[443]}], msg_controllen=20, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 20
close(443)                              = 0
sendmsg(136, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\0\0\0\f\0001\0\0\0", iov_len=12}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 12
poll([{fd=136, events=POLLIN}], 1, -1)  = 1 ([{fd=136, revents=POLLIN}])
recvmsg(136, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="1\0\0\0\0\0\f\0v{\0\0\1\0\0\0\1\0\f\0001\0\0\0", iov_len=1656}, {iov_base="", iov_len=2440}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(136, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resursen tillfälligt otillgänglig)
read(430, 

The call to read never returns.

If I read correctly (and it is very possible I don’t!!) brave creates the two file descriptors of a pipe (430 read, 441 write). It duplicates the write pipe (443) and sets some flag (CLOEXEC). then closes the original descriptor (441), leaving only the duplicate. Then closes the duplicate too (443). Then attempts to read from the read end (430) where nothing happens, since all write ends were closed.

It looks like Brave wants to run a command and capture the output but changes its mind about running the command.

Original poster here. I am using the beta version (Version 1.71.104 Chromium: 129.0.6668.89 (Official Build) beta (64-bit))

This problem does not occur with Chrome Version 129.0.6668.90 (Official Build) (64-bit)

So far I have not been able to repro with the guest profile.

[edit] I was able to repro with the guest profile.

@yngwe,
Would you be willing to run the Guest profile test for me and confirm whether or not the issue persists?

Yes I was able to repro with the guest profile.

I am trying to repro but today, the problem does not seem to happen.

I am keeping this version (1.70.123) until I get it to break again.

When it was working, I ran strace like above. The result are below:

pipe2([438, 457], 0)                    = 0
fcntl(457, F_DUPFD_CLOEXEC, 0)          = 458
close(457)                              = 0
sendmsg(130, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\2\0\0\377\1\0(\0\31\0\0\0text/plain;charset=u"..., iov_len=40}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[458]}], msg_controllen=20, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 40
close(458)                              = 0
sendmsg(130, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\0\0\0\f\0001\0\0\0", iov_len=12}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 12
poll([{fd=130, events=POLLIN}], 1, -1)  = 1 ([{fd=130, revents=POLLIN}])
recvmsg(130, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="1\0\0\0\0\0\f\0\266f\0\0\1\0\0\0\1\0\f\0001\0\0\0", iov_len=4080}, {iov_base="", iov_len=16}], msg_iovlen=2, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(130, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resursen tillfälligt otillgänglig)
read(438, "Batman Arkham Knight,", 1024) = 21
read(438, "", 1024)                     = 0

this is exactly the same sequence of calls. It ends with successful reads this time. The text was what was in my clipboard today. I can unfortunately not tell you what I had in my clipboard at the time of the issue.

OK I have a solid repro.

I program using CLion (my expectation is that it’d work with any kind of smart clipboard application)
if I copy some file/folder in CLion then close CLion, then open Brave 1.70 and click on the title bar, then Brave can lock up.

It’s important to close the application (the source of the clipboard content is closed).

1.69: Brave will lock up if I have some content in the clipboard like above, then click on the address bar, then paste the content. Deadlock.

If I run the same thing in a guest profile, I get the same deadlock.

1.70: Brave will lock up if I have some content in the clipboard like above, then click on the address bar. I don’t need to try and paste. It seems to be that Brave wants to access the clipboard content at an earlier point.

1.71 (beta): does not seem to lock up in any way.

I was just able to repro with 1.71. But it might be a different problem.

New tab, select address bar, try to type, locked up for about 15 seconds.

If I select a different tab I can interact within the tab but going back to the new tab will cause a 15 second lock up.

Version 1.71.104 Chromium: 129.0.6668.89 (Official Build) beta (64-bit)

@yngwe,
Thank you for the repo steps. I suspect that this issue will be resolved when the current Beta version (1.71.x) gets pushed to release, which should be this Thursday. Once you update the stable build to 1.71.x on Thursday, if you are still seeing this issue please let me know and we will open an issue for this and I’ll ping some devs internally to take a look.

1 Like

What is up with this release? I still struggle with this issue and i still see only 1.70.x in the about brave screen.

1 Like

I have now installed version 1.71.114 of Brave. However, I still have the problem that Brave freezes when I click the address bar.
Is this problem still pending with the developers?

I encountered the issue again in 1.71.114 Chromium: 130.0.6723.58 (Officiell version) (64 bitar)

same repro as above: copy files in CLion/IntelliJ then closing the program, Brave deadlocks when I click on the address bar.
I cannot repro using other applications such as Dolphin though. But I don’t really do a lot of copy/pasting in general.