[Bug]: Linux: In french locale, crash on access of user-selected file with accent in filename

Question

[Bug]: Linux: In french locale, crash on access of user-selected file with accent in filename

scottnonnenberg-signal opened this issue 2 years ago · comments

Scott Nonnenberg commented 2 years ago

Preflight Checklist

I have read the Contributing Guidelines for this project.
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

19.0.6

What operating system are you using?

Ubuntu

Operating System Version

22.04, Arch Linux and Fedora Silverblue

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

Open any file, no matter the characters in the filename

Actual Behavior

Start application with LANG=fr_FR.UTF-8, then with the file picker open a file with an accent in it (like tèst.txt), then try to grab the ArrayBuffer representation of the Blob returned on the 'change' event. See the attached fiddle to make this very easy.

We see this in the console, and the renderer window becomes unresponsive:

[17157:0701/162155.959753:ERROR:bad_message.cc(29)] Terminating renderer for bad IPC message, reason 2

If we listen to the 'renderer-process-gone' event, we see this:

Error: Reason: killed, Exit Code: 3

This simple text file is enough to trigger it: tèst.txt

Testcase Gist URL

https://gist.github.com/e8572fe7198586d84a8f1d0b2ae3224f

Additional Information

This was originally reported by a Signal Desktop user here: signalapp/Signal-Desktop#5977 (comment)

WhiteNoiseDev commented a year ago

bump

Charles Kerr · Answer 1 · Thu Jul 07 2022 01:24:48 GMT+0800 (China Standard Time)

I tested with some older versions to see if this is a new regression.

This issue also exists in

16.0.0
16.2.8 (latest stable 16)
17.0.0
17.4.9 (latest stable 17)
18.0.0
18.3.5 (latest stable 18)

Behaves just as @scottnonnenberg-signal reports. LANG=fr_FR.UTF-8 was needed for me to reproduce; it did not happen in LANG=en_US.UTF-8

Thibault Molleman · Answer 2 · Fri Sep 02 2022 21:10:24 GMT+0800 (China Standard Time)

This issue is affecting Obsidian (electron based) https://forum.obsidian.md/t/images-dont-load-if-vault-contains-non-standard-letters-such-as-e/42010/22
I did some testing (see that forum post) and it seems like it's not just French though.
But the main thing I noticed trough my testing was that it seems like it's not related to what language of the linux distro is installed. But what you change the 'formats' to.
I tested out a vm with manjaro installed in French. The obsidian bug wasn't reproducable.
But as with my other tests, if you change the 'formats/region' value to something else (and then restart the session). That's what breaks it.
Although changing my french manjaro install to Dutch (belgium), didn't seem to break it.
So I think it's related to the language that the OS is installed with not having special charachters. But if you change it to a locale that does, then it breaks

Charles Kerr · Answer 3 · Wed Sep 21 2022 00:51:06 GMT+0800 (China Standard Time)

I'm still getting a handle on this issue, but a partial status update: what's happening is wcrtomb() is failing in base::SysWideToNativeMB. It doesn't seem to be limited to combining characters, e.g. the combining grave accent in the original testcase (tèst.txt); the same code is erroring out when using a non-combination char (e.g. rést.txt using latin small letter e with acute also fails).

mbtowc() converts from a multibyte character encoded in the current locale to a wchar_t, which is likely the root of the problem.

One other point, most of the code in play here is all upstream Chromium -- but AFAICT there's no similar upstream bug so Electron is likely introducing something into the process that breaks this locale, but I'm not yet seeing how.

Charles Kerr · Answer 4 · Wed Sep 21 2022 01:00:50 GMT+0800 (China Standard Time)

wcrtomb errno 84 Invalid or incomplete multibyte or wide character

backtrace from the mbtowc() calll:

#7 0x55dfcccbf213 base::SysWideToNativeMB()
#8 0x55dfccbb9411 _ZN4base8FilePath15FromUTF16UnsafeENS_16BasicStringPieceIDsNSt2Cr11char_traitsIDsEEEE
#9 0x55dfd01854f9 blink::StringToFilePath()
#10 0x55dfd0185751 blink::WebStringToFilePath()
#11 0x55dfcb42c285 blink::BlobData::CreateForFileWithUnknownSize()
#12 0x55dfcf511f77 blink::File::File()
#13 0x55dfcf3df0cc blink::File::CreateForUserProvidedFile()
#14 0x55dfd04703e5 blink::FileInputType::CreateFileList()
#15 0x55dfd0471944 blink::FileInputType::FilesChosen()
#16 0x55dfcfcdc19b blink::FileChooser::DidChooseFiles()
#17 0x55dfcfcdd116 base::internal::Invoker<>::RunOnce()
#18 0x55dfcfcdd2b5 WTF::ThreadCheckingCallbackWrapper<>::RunInternal()
#19 0x55dfcfcdd022 WTF::ThreadCheckingCallbackWrapper<>::Run()
#20 0x55dfcfcdd226 base::internal::Invoker<>::RunOnce()
#21 0x55dfcb2c91ce blink::mojom::blink::FileChooser_OpenFileChooser_ForwardToCallback::Accept()
#22 0x55dfcd042db8 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#23 0x55dfcd04265e mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept()
#24 0x55dfcd04b89b mojo::MessageDispatcher::Accept()
#25 0x55dfcd0448fd mojo::InterfaceEndpointClient::HandleIncomingMessage()
#26 0x55dfcd051d3a mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#27 0x55dfcd0511bb mojo::internal::MultiplexRouter::Accept()

Charles Kerr · Answer 5 · Wed Sep 21 2022 11:28:30 GMT+0800 (China Standard Time)

I take that earlier comment back -- this is an upstream bug; a variant of it is happening in Chromium too.

To reproduce:

launch with LANG set, same as in this issue: $ LANG=fr_FR.UTF-8 google-chrome
ctrl-o and try to open the file, same as in this issue, e.g. rést.txt

Expected result:

rést.txt is opened

Actual result:

/ is opened

Electron is clearly taking it one step further by crashing, but you may want to also report this upstream to Chromium.

github-actions · Answer 6 · Wed Jan 11 2023 10:02:36 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

Thibault Molleman · Answer 7 · Wed Jan 11 2023 12:54:18 GMT+0800 (China Standard Time)

This bug is still relevant

github-actions · Answer 8 · Thu Apr 13 2023 09:53:19 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

ScottZ123 · Answer 9 · Thu May 25 2023 15:50:11 GMT+0800 (China Standard Time)

This bug is still relevant

github-actions · Answer 10 · Thu Aug 24 2023 09:47:25 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

WhiteNoiseDev · Answer 11 · Mon Aug 28 2023 01:43:30 GMT+0800 (China Standard Time)

Still a problem

SrIzan10 · Answer 12 · Sat Jan 20 2024 00:59:14 GMT+0800 (China Standard Time)

Hey! I had trouble with obsidian on Flatpak but when installing via the Arch extra repo it looks like it's working.
Just leaving it here if anyone has the same issue as me.