Thanks!
I can confirm that PyCharm works correctly (x86_64-linux) , including markdown, jupyter cells and the cursor theme.

Edit: A segfault happened while checking a Jupyter file. Previous success was due to caching? At this point I think it's an unrelated issue, but it would be better if other users could confirm or deny this.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f1eff9f1734, pid=10036, tid=10217
#
# JRE version: OpenJDK Runtime Environment JBR-21.0.7+1-1038.58-jcef (21.0.7+1) (build 21.0.7+1-b1038.58)
# Java VM: OpenJDK 64-Bit Server VM JBR-21.0.7+1-1038.58-jcef (21.0.7+1-b1038.58, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libjcef.so+0x1f1734]  std::__codecvt_utf8_utf16_base<char32_t>::do_unshift(__mbstate_t&, char*, char*, char*&) const+0x4
JNI global refs:
JNI global refs: 100, weak refs: 187

JNI global refs memory usage: 1491, weak refs: 2753

OOME stack traces (most recent first):
Classloader memory used:
Loader com.intellij.util.lang.PathClassLoader                                          : 115M
Loader bootstrap                                                                       : 35573K
Loader com.intellij.ide.plugins.cl.PluginClassLoader                                   : 30500K
Loader jdk.internal.loader.ClassLoaders$AppClassLoader                                 : 837K
Loader jdk.internal.loader.ClassLoaders$PlatformClassLoader                            : 441K
Loader sun.reflect.misc.MethodUtil                                                     : 3064B

Classes loaded by more than one classloader:
Class com.intellij.ultimate.PluginVerifier                                            : loaded 2 times (x 69B)

# An error report file with more information is saved as:
# /home/user/java_error_in_pycharm_10036.log
#
# If you would like to submit a bug report, please visit:
#   https://youtrack.jetbrains.com/issues/JBR
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
3670 [ERROR] xplat_launcher::java: [JVM] abort_hook

[error occurred during error reporting (), id 0x6, SIGABRT (0x6) at pc=0x00007f2005a9cf3c]

Thanks for the PR!

It seems that many changes are similar to #425529. Shall we converge to one PR to reduce the work for the committers?

Maybe we can reduce this PR to an update and address the fix in #425529

Thanks for the PR!

It seems that many changes are similar to #425529. Shall we converge to one PR to reduce the work for the committers?

Maybe we can reduce this PR to an update and address the fix in #425529

The main reason I created a new PR is because I believe the changes in #425529 to be a bit too invasive. I'm not sure why there is a block which skips the configureFlags partially. The adding of the format -Wno-error=... arguments becomes redundant by updating the runtime to a newer version (these compile warnings were fixed). These are also fixed by inheriting oldAttrs.env.

I'm not strictly against combining these PR's, but I think the changes in this PR don't actually require the changes in #425529

Thanks! I can confirm that PyCharm works correctly (x86_64-linux) , including markdown, jupyter cells and the cursor theme.

Edit: A segfault happened while checking a Jupyter file. Previous success was due to caching? At this point I think it's an unrelated issue, but it would be better if other users could confirm or deny this.

Honestly no idea. I'd blame this on JCEF, but to be fair, I think we're also mixing a combination of JCEF and JBR that is not how upstream combines the versions.

It would be interesting to see the /home/user/java_error_in_pycharm_10036.log file mentioned in the crash report, it should contain more information on whats going on

@acid-bong I'm not entirely sure if the commit messages and PR title are now ok, especially the ones which touch multiple packages. Maybe you have a better idea on naming them

I also got segfault while trying to open a markdown file using idea-community-bin.
java_error_in_idea_1707817.log

This might be related: https://youtrack.jetbrains.com/issue/JBR-8199/PyCharm-Crashes-with-2024.3.2 and https://youtrack.jetbrains.com/issue/JBR-5948/Intellij-crash-at-C-libstdc.so.60xd2194-stdcodecvtutf8utf16basechar16tdounshift

Does the workaround help? I couldn't yet reproduce this. I would declare this a Jetbrains issue to be open, though chances are this could be solved by updating the used JCEF (and maybe building the CEF binaries from source, they are currently downloaded pre-built and then patched)

Does the workaround help? I couldn't yet reproduce this. I would declare this a Jetbrains issue to be open, though chances are this could be solved by updating the used JCEF (and maybe building the CEF binaries from source, they are currently downloaded pre-built and then patched)

I can't test workaround or help with this PR any further due to being away from my main PC, however here are several important details:

Before attempting to reproduce this issue on any project, make sure you remove the jcef cache (for example ~/.cache/JetBrains/PyCharm2025.1/jcef_cache).

I didn't remove the cache while checking this PR, so it probably segfaults too. And another one is confirmed to segfault.

This is very unlikely to be a JetBrains issue. It happens with both old and new jbr-jcef when:

separateDebugInfo = true;
__structuredAttrs = true;

I guess having both set to true has the side effect of changing some sneaky environment variable (no idea which one) during building process and that causes segfault later.

For now I've overridden both to false:

separateDebugInfo = false;
__structuredAttrs = false;

And everything works as expected.

Oh great... maybe this really is the way then, even if its quick and dirty. I have the feeling figuring out why JCEF randomly segfaults is a not insubstantial amount of work.

Does the workaround help?

I didn't try to change the permission of the chrome-sandbox but "enable out-of-process JCEF via registry" does not work for me.

I didn't remove the cache while checking #425529, so it probably segfaults too.

idea-community-bin does not segfault with #425529 even after the jcef_cache is removed.

Rebased after merging #425529

@aoli-al since this was now rebased on top of #425529, can you check again if you can reproduce the segfault? I suppose this really now is just an update PR

Had to repush due to a nix fmt error: https://github.com/NixOS/nixpkgs/actions/runs/16505373386/job/46674511731

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 426285
Commit: 50fbd3334953a47b0bae0c9f88b98432c735fcfe

x86_64-linux