glib2 fix breaks link opening functionality in Brave

danniel3 commented 1 year ago

Description

Opening a link from outside of Brave on opens the link 3 times. It does this when opening links from Slack, ClickUp and other applications, as well as via scripts based on links in the terminal (eg. a link handler taking links from Newsboat and sending them to the $BROWSER).

This is due to the glib 2.76 update, which fundamentally altered the memory management in glib clients, exposing a lot of bugs in apps like yours.

Steps to Reproduce

Open Brave
Click on a website link in a program other than Brave (eg. Slack, ClickUp, etc.)

Actual result:

The link will open in 3 tabs
A coredump is generated 3 times

Expected result:

The link should only open once

Reproduces how often:

Happens every single time I open a link from another app or via my linkhandler terminal script.

This behaviour only started after the March 12 glib2 update. It was working perfectly fine before then.

Brave version (brave://version info)

Brave | 1.49.120 Chromium: 111.0.5563.64 (Official Build) (64-bit) Revision | c710e93d5b63b7095afe8c2c17df34408078439d-refs/branch-heads/5563@{#995} OS | Linux JavaScript | V8 11.1.277.13

Additional info:

Running Arch Linux
Installed via aur from brave-bin
Running dwm

Version/Channel Information:

N/A

Other Additional Information:

I saw this post regarding the same problem on the Arch Linux Forums.

And a recent thread on Arch Linux Forums:

glib2 in 2005 or so introduced some high level memory management to deal w/ (actual) issues in malloc. The consequence was that code using this approach to alloc/free memory could get away w/ accessing "stale" memory segments, because they were not immediately released.

When memory is accessed from multiple locations and based on event loop handling, maybe even multiple threads you need to pay some attention to keep your data structures up-to date and aligned. It matters when you free stuff, because that cannot happen before everything else got the message to no longer look there. This was "eased" w/ g_slice because the memory was (often) not in fact freed immediately, effectively defaulting to Qt's ::deleteLater()

Even though I don't think that was sold as a feature, it was a reality and all sorts of code will have relied on that (because memory management can be hard, poking this way made the code not crash, yay!)

glib2 2.76 has effectively removed the training wheels and pushed you from the front yard onto the Autobahn in one move. But they've not introduced a bug. They just expose all the broken code they've enabled for decades.

Miscellaneous Information:

N/A

EricDriussi commented 1 year ago

Was writing a bug report of my own but since this is already here and with pretty much the same behavior/versions I'll just leave a lazy "me too" comment :)

LennyPhoenix commented 1 year ago

Am experiencing the same problem:

~
❯ brave --version
Brave Browser 111.1.49.120

~
❯ yay -Qi glib2
Name            : glib2
Version         : 2.76.0-1

brave / brave-browser