[Bug]: Desktop main process SIGTRAPs when dragging a file with non-ASCII characters and a space in its name into the composer (Linux/Wayland) #13746

Activity

1. juliusmarminge commented on Sep 26, 2026

   

   juliusmarminge

   on Sep 26, 2026

   Member

   More actions

   This is an Electron/Chromium crash, not the composer attachment code. Dropping a file on Linux Wayland is handled in the browser process before makeWorkspaceFileDropHandlers or addComposerAttachments run. Those only see a File after Chromium has accepted the drop. The SIGTRAP with si_code: SI_KERNEL is Chromium's fatal check, and the dump is the t3code main process, so the window and the bundled server both go away. A renderer crash would be reloaded; this one is not.

   The same signature is already tracked upstream in electron/electron#54153 (Electron 44.4.3, KDE Wayland, non-ASCII filename, ASCII rename works, file bytes irrelevant). Maintainers reproduced it on Chrome and closed it as upstream on September 24. It is not fixed. This repo is still on Electron 44.4.2, including the nightlies you tested. The mime.cache line is unrelated Chromium noise; it also shows up for drops that attach.

   The space is probably not required. Both of your failing names contain non-ASCII characters, and the Electron report crashes on an em dash alone. Renaming to ASCII is the workaround that is known to work. The paperclip button uses the file chooser (<input type="file">) instead of the Wayland drag path, so it may also work. That is not confirmed.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   upstream

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 26, 2026
3. marcuscastelo commented on Sep 26, 2026

   

   marcuscastelo

   on Sep 26, 2026

   Author

   More actions

   Root cause found. This is not a T3 Code bug. It is a Chromium CHECK in the browser process, triggered because the process runs with a non-UTF-8 LC_CTYPE. The space in the name is irrelevant; one non-ASCII character is enough.

   Symbolized stack

   I symbolized the core dump with the official Electron 44.4.2 breakpad symbols (build-id e3816f4c… matches). Main thread:

   content::PathInfo::PathInfo(PathType, FilePath, std::string)  base/immediate_crash.h:180
   content::FileInfosToDataTransferFiles(...)          content/browser/renderer_host/data_transfer_util.cc:118
   content::DropDataToDragData(...)                    data_transfer_util.cc:231
   content::RenderWidgetHostImpl::DragTargetDrop(...)  render_widget_host_impl.cc:2121
   content::WebContentsViewAura::CompleteDrop(...)     web_contents_view_aura.cc:1875
   ...
   ui::WaylandDataDragController::OnDragDrop(...)      wayland_data_drag_controller.cc:571
   ui::WaylandDataDevice::OnDrop(...)                  wayland_data_device.cc:151
   

   The crash happens while Chromium converts the drop, before the renderer receives any drag event. No T3 Code code (composer, preload, IPC) runs.

   Why

   • data_transfer_util.cc:114 checks that the FilePath display name is non-empty, but line 118 passes display_name.AsUTF8Unsafe() to PathInfo, which does CHECK(!display_name.empty()) (file_system_access_permission_context.h:85).
   • On desktop Linux, AsUTF8Unsafe() goes through SysNativeMBToWide() / mbrtowc(), which returns an empty string for any non-ASCII byte when LC_CTYPE is C.
   • content_main.cc calls setlocale(LC_ALL, ""). glibc fails that call as a whole when any locale variable names a locale that is not installed. On my machine, KDE's Region settings export LC_TIME=en_GB.UTF-8, but only en_US.UTF-8 is generated. So the process stays in C even though LANG=en_US.UTF-8.

   I replayed the same libc calls with the app's environment:

   == LANG=en_US.UTF-8 LC_TIME=en_GB.UTF-8 (en_GB not installed):
   setlocale(LC_ALL, "") returned: NULL   -> LC_CTYPE: C
     'ação b.txt': mbstowcs -> -1
     'ação.txt':   mbstowcs -> -1
     'a b.txt':    mbstowcs -> 7
     'plain.txt':  mbstowcs -> 9
   == LANG=en_US.UTF-8 only:
   setlocale(LC_ALL, "") returned: en_US.UTF-8   (all names convert)
   

   Workaround

   Make every locale variable name an installed locale, for example by enabling en_GB.UTF-8 UTF-8 in /etc/locale.gen and running locale-gen, or by setting LC_TIME to an installed locale. LC_ALL=C reproduces the crash.

   T3 Code cannot work around this: the locale is fixed by Chromium before any app JavaScript runs, and the crash happens before the drop reaches the renderer.

   Same crash upstream: electron/electron#54153 (Electron maintainers confirmed it reproduces in Chrome and asked for an upstream Chromium report) and probably electron/electron#49804 ("crashes when launched from the desktop file, not from a terminal"). I'm filing the Chromium report and will link it here.
4. marcuscastelo commented on Sep 26, 2026

   

   marcuscastelo

   on Sep 26, 2026

   Author

   More actions

   Closing: this is not a T3 Code bug. It is a Chromium crash in the browser process, and it only happens when the process runs with a non-UTF-8 LC_CTYPE. Summary for anyone who lands here with the same symptom (the detailed analysis is in the comment above).

   Symptom

   On Linux, dropping a file whose name contains any non-ASCII character (ação.txt, repro — test.md, …) onto an Electron/Chromium window kills the main process with SIGTRAP (si_code: SI_KERNEL). Nothing is logged, and no dragenter/dragover/drop handler runs. ASCII names work, and the space in the name is irrelevant. It affects any Electron app, not only T3 Code.

   Root cause

   Symbolized stack (Electron 44.4.2 = Chromium 152.0.7977.130, official breakpad symbols):

   content::PathInfo::PathInfo(PathType, FilePath, std::string)  base/immediate_crash.h:180
   content::FileInfosToDataTransferFiles(...)          content/browser/renderer_host/data_transfer_util.cc:118
   content::DropDataToDragData(...)                    data_transfer_util.cc:231
   content::RenderWidgetHostImpl::DragTargetDrop(...)  render_widget_host_impl.cc:2121
   content::WebContentsViewAura::CompleteDrop(...)     web_contents_view_aura.cc:1875
   ...
   ui::WaylandDataDragController::OnDragDrop(...)      wayland_data_drag_controller.cc:571
   ui::WaylandDataDevice::OnDrop(...)                  wayland_data_device.cc:151
   

   1. content_main.cc calls setlocale(LC_ALL, "") at startup. glibc fails that whole call, and leaves every category at C, when any locale variable names a locale that is not installed. In my case KDE's Region settings exported LC_TIME=en_GB.UTF-8 while only en_US.UTF-8 was generated, so the process ran in C even though LANG=en_US.UTF-8.
   2. On a drop, FileInfosToDataTransferFiles() checks that the FilePath display name is non-empty (line 114), but passes display_name.AsUTF8Unsafe() to PathInfo (line 118).
   3. On desktop Linux, AsUTF8Unsafe() converts through SysNativeMBToWide()/mbrtowc(), which returns an empty string for any non-ASCII byte in the C locale.
   4. PathInfo then hits CHECK(!this->display_name.empty()) (content/public/browser/file_system_access_permission_context.h:85), and the browser process traps.

   The crash happens before the drop reaches the renderer, and the locale is fixed before any app JavaScript runs, so T3 Code cannot work around it. The same code is still on Chromium main.

   Am I affected?

   Run locale from the same environment that launches the app. Lines like locale: Cannot set LC_ALL to default locale: No such file or directory mean yes. Compare your LANG/LC_* values with locale -a. Launching from a terminal can behave differently from launching from the desktop menu if the session exports extra LC_* variables, which matches the "only crashes when launched from the GUI" report in electron/electron#49804.

   Fix

   Make every LANG/LC_* variable name an installed locale. On Arch: uncomment the locale in /etc/locale.gen and run locale-gen, or change the variable (for example in KDE's Region settings) to a locale you have. Restart the app afterwards. LC_ALL=C reproduces the crash on purpose.

   Upstream

   • Crash (SIGTRAP) on drag-and-drop of a file whose filename contains a non-ASCII character (U+2014) — Linux/Wayland electron/electron#54153: the same crash. Electron maintainers confirmed it reproduces in Chrome and asked for an upstream Chromium report.
   • Crash on drag and drop with a Unicode file extension on Linux electron/electron#49804: very likely the same bug.
   • The Chromium-side fix is to guard on the converted string instead of the FilePath in data_transfer_util.cc (or to convert without depending on the C library locale). Note that the PathInfo(PathType, FilePath) constructors derive the display name the same way, so other File System Access entry points may hit the same CHECK in a C-locale process.
5. marcuscastelo

   closed this as not plannedon Sep 26, 2026