-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
rhel-10.0.beta
-
None
-
None
-
sst_pt_libraries
-
ssg_platform_tools
-
3
-
False
-
-
None
-
Red Hat Enterprise Linux
-
None
-
None
-
None
-
-
Unspecified
-
None
What were you trying to do that didn't work?
After booting the guest, this error message appears in the current guest's dmesg:
[ 24.804240] gnome-shell[2272]: segfault at 564c1e174f8b ip 00007ff3da05a6ad sp 00007ff34affee90 error 4 in libc.so.6[7ff3da03f000+15f000] likely on CPU 13 (core 1, socket 1
Please provide the package NVR for which bug is seen:
kernel-6.10.0-0.rc2.10.el10.x86_64
qemu-kvm-9.0.0-2.el10.x86_64
gnome-shell-46.2-3.el10.x86_64
edk2-ovmf-20240214-1.el10.noarch
How reproducible:
100%
Steps to reproduce
1. Boot a guest
/usr/libexec/qemu-kvm \
-name 'avocado-vt-vm1' \
-sandbox on,elevateprivileges=deny,obsolete=deny,resourcecontrol=deny \
-blockdev '{"node-name": "file_ovmf_code", "driver": "file", "filename": "/usr/share/OVMF/OVMF_CODE.secboot.fd", "auto-read-only": true, "discard": "unmap"}' \
-blockdev '{"node-name": "drive_ovmf_code", "driver": "raw", "read-only": true, "file": "file_ovmf_code"}' \
-blockdev '{"node-name": "file_ovmf_vars", "driver": "file", "filename": "/root/avocado/data/avocado-vt/avocado-vt-vm1_rhel100-64-virtio-scsi-ovmf_qcow2_filesystem_VARS.raw", "auto-read-only": true, "discard": "unmap"}' \
-blockdev '{"node-name": "drive_ovmf_vars", "driver": "raw", "read-only": false, "file": "file_ovmf_vars"}' \
-machine q35,pflash0=drive_ovmf_code,pflash1=drive_ovmf_vars,memory-backend=mem-machine_mem \
-device '{"id": "pcie-root-port-0", "driver": "pcie-root-port", "multifunction": true, "bus": "pcie.0", "addr": "0x1", "chassis": 1}' \
-device '{"id": "pcie-pci-bridge-0", "driver": "pcie-pci-bridge", "addr": "0x0", "bus": "pcie-root-port-0"}' \
-nodefaults \
-device '{"driver": "VGA", "bus": "pcie.0", "addr": "0x2"}' \
-m 29696 \
-object '{"size": 31138512896, "id": "mem-machine_mem", "qom-type": "memory-backend-ram"}' \
-smp 24,maxcpus=24,cores=12,threads=1,dies=1,sockets=2 \
-cpu 'Icelake-Server-noTSX',+kvm_pv_unhalt \
-device '{"id": "pcie-root-port-1", "port": 1, "driver": "pcie-root-port", "addr": "0x1.0x1", "bus": "pcie.0", "chassis": 2}' \
-device '{"driver": "qemu-xhci", "id": "usb1", "bus": "pcie-root-port-1", "addr": "0x0"}' \
-device '{"driver": "usb-tablet", "id": "usb-tablet1", "bus": "usb1.0", "port": "1"}' \
-device '{"id": "pcie-root-port-2", "port": 2, "driver": "pcie-root-port", "addr": "0x1.0x2", "bus": "pcie.0", "chassis": 3}' \
-device '{"id": "virtio_scsi_pci0", "driver": "virtio-scsi-pci", "bus": "pcie-root-port-2", "addr": "0x0"}' \
-blockdev '{"node-name": "file_image1", "driver": "file", "auto-read-only": true, "discard": "unmap", "aio": "threads", "filename": "/home/kvm_autotest_root/images/rhel100-64-virtio-scsi-ovmf.qcow2", "cache": {"direct": true, "no-flush": false}}' \
-blockdev '{"node-name": "drive_image1", "driver": "qcow2", "read-only": false, "cache": {"direct": true, "no-flush": false}, "file": "file_image1"}' \
-device '{"driver": "scsi-hd", "id": "image1", "drive": "drive_image1", "write-cache": "on"}' \
-device '{"id": "pcie-root-port-3", "port": 3, "driver": "pcie-root-port", "addr": "0x1.0x3", "bus": "pcie.0", "chassis": 4}' \
-device '{"driver": "virtio-net-pci", "mac": "9a:f0:1d:2d:b2:14", "id": "idNeZ8UC", "netdev": "id0VKDVg", "mq": true, "vectors": 34, "bus": "pcie-root-port-3", "addr": "0x0"}' \
-netdev '{"id": "id0VKDVg", "type": "tap", "vhost": true, "queues": 16}' \
-vnc :0 \
-rtc base=utc,clock=host,driftfix=slew \
-boot menu=off,order=cdn,once=c,strict=off \
-enable-kvm \
-device '{"id": "pcie_extra_root_port_0", "driver": "pcie-root-port", "multifunction": true, "bus": "pcie.0", "addr": "0x3", "chassis": 5}' \
-monitor stdio \
-serial unix:/tmp/monitor1,server,nowait \
2. Guest dmesg appears error messges:
[ 24.908333] gnome-shell[2432]: segfault at 55acac557026 ip 00007f5d4ca5a6ad sp 00007f5cc1bfee90 error 4 in libc.so.6[7f5d4ca3f000+15f000] likely on CPU 23 (core 11, socket 1)^M [ 24.908345] Code: 84 e4 74 59 e8 74 4e fe ff 48 8b 5d 00 49 89 c6 48 85 db 75 15 eb 36 66 0f 1f 44 00 00 48 8b 5d 08 48 83 c5 08 48 85 db 74 23 <44> 3a 23 75 ee 4c 89 f2 48 89 de 4c 89 ef e8 30 4f fe ff 85 c0 75^M
Expected results
guest dmesg no such error messages
Actual results
guest dmesg appears error messges: gnome-shell[2432]: segfault
[RHEL-42410] glibc: Provide thread-safe getenv [rhel-10]
Pinned comments
Florian Weimer
added a comment - - edited I made a glibc test build with a getenv function that is thread-safe in more cases:
https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
Install it using:
dnf update --nogpgcheck --repofrompath=RHEL-42410,https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
This is still a preview, some further enhancements are needed to avoid false negative results with concurrent unsetenv , and the documentation updates need to be written.
A more complete patch has been submitted upstream:
[PATCH] stdlib: Make getenv thread-safe in more cases
All comments
I made a glibc test build with a getenv function that is thread-safe in more cases:
Install it using:
dnf update --nogpgcheck --repofrompath=RHEL-42410,https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
This is still a preview, some further enhancements are needed to avoid false negative results with concurrent unsetenv, and the documentation updates need to be written.
A more complete patch has been submitted upstream:
Florian Weimer
added a comment - - edited I made a glibc test build with a getenv function that is thread-safe in more cases:
https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
Install it using:
dnf update --nogpgcheck --repofrompath=RHEL-42410,https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
This is still a preview, some further enhancements are needed to avoid false negative results with concurrent unsetenv , and the documentation updates need to be written.
A more complete patch has been submitted upstream:
[PATCH] stdlib: Make getenv thread-safe in more cases
All comments
Zhiyi Guo
added a comment - Does this issue block you?
I have no objection to your plan to include the fix into rhel 10.0 GA
Zhiyi Guo
added a comment - fweimer@redhat.com
Does this issue block you?
I have no objection to your plan to include the fix into rhel 10.0 GA Florian Weimer
added a comment - rhn-support-zhguo Thank you for testing! Does this issue block you?
I plan to prose completing the upstream fix and pitch its inclusion in to RHEL 10, but unless this needs an urgent fix, it will take some time until integration into RHEL 10 (2024-08-19 is the end of SST PT Libraries Sprint 8).
Florian Weimer
added a comment - rhn-support-zhguo Thank you for testing! Does this issue block you?
I plan to prose completing the upstream fix and pitch its inclusion in to RHEL 10, but unless this needs an urgent fix, it will take some time until integration into RHEL 10 (2024-08-19 is the end of SST PT Libraries Sprint 8). Zhiyi Guo
added a comment - For nvidia gpu passthrough use case, I don't see gnome-shell crash with https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
Zhiyi Guo
added a comment - For nvidia gpu passthrough use case, I don't see gnome-shell crash with https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/ It could be a duplicated of https://issues.redhat.com/browse/RHEL-39677. The stack trace also points to getenv. From RHEL-39677:
Stack trace of thread 1713:
#0 0x00007f045826cd4d getenv (libc.so.6 + 0x43d4d)
#1 0x00007f0456adf3c3 FcConfigCreate (libfontconfig.so.1 + 0x93c3)
#2 0x00007f0456aeb4d5 FcInitLoadOwnConfig (libfontconfig.so.1 + 0x154d5)
#3 0x00007f0456ae6dad FcConfigEnsure.lto_priv.0 (libfontconfig.so.1 + 0x10dad)
#4 0x00007f0456aeb76d FcInit (libfontconfig.so.1 + 0x1576d)
#5 0x00007f0456b30065 fc_thread_func (libpangoft2-1.0.so.0 + 0xb065)
#6 0x00007f0458b0adf2 g_thread_proxy (libglib-2.0.so.0 + 0x89df2)
#7 0x00007f04582bd812 start_thread (libc.so.6 + 0x94812)
#8 0x00007f045832d27c __clone3 (libc.so.6 + 0x10427c)
Jose Exposito Quintana
added a comment - - edited It could be a duplicated of https://issues.redhat.com/browse/RHEL-39677 . The stack trace also points to getenv. From RHEL-39677:
Stack trace of thread 1713:
#0 0x00007f045826cd4d getenv (libc.so.6 + 0x43d4d)
#1 0x00007f0456adf3c3 FcConfigCreate (libfontconfig.so.1 + 0x93c3)
#2 0x00007f0456aeb4d5 FcInitLoadOwnConfig (libfontconfig.so.1 + 0x154d5)
#3 0x00007f0456ae6dad FcConfigEnsure.lto_priv.0 (libfontconfig.so.1 + 0x10dad)
#4 0x00007f0456aeb76d FcInit (libfontconfig.so.1 + 0x1576d)
#5 0x00007f0456b30065 fc_thread_func (libpangoft2-1.0.so.0 + 0xb065)
#6 0x00007f0458b0adf2 g_thread_proxy (libglib-2.0.so.0 + 0x89df2)
#7 0x00007f04582bd812 start_thread (libc.so.6 + 0x94812)
#8 0x00007f045832d27c __clone3 (libc.so.6 + 0x10427c)
When booting a rhel 10.0 beta VM with a passthrough nvidia RTX 2000 ada gpu and remove the 61-gdm.rules, looks like I always hit the same issue. For the crash calltrace, please refer to crash.txt I have uploaded
The package info from the guest:
mutter-46.3-1.el10.x86_64 gnome-shell-46.3.1-3.el10.x86_64 kernel-6.10.0-0.rc5.12.el10.x86_64 nvidia driver 555.58.02 in open gpu driver mode
Zhiyi Guo
added a comment - - edited When booting a rhel 10.0 beta VM with a passthrough nvidia RTX 2000 ada gpu and remove the 61-gdm.rules, looks like I always hit the same issue. For the crash calltrace, please refer to crash.txt I have uploaded
The package info from the guest:
mutter-46.3-1.el10.x86_64
gnome-shell-46.3.1-3.el10.x86_64
kernel-6.10.0-0.rc5.12.el10.x86_64
nvidia driver 555.58.02 in open gpu driver mode
I made a glibc test build with a getenv function that is thread-safe in more cases:
Install it using:
dnf update --nogpgcheck --repofrompath=RHEL-42410,https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
This is still a preview, some further enhancements are needed to avoid false negative results with concurrent unsetenv, and the documentation updates need to be written.
A more complete patch has been submitted upstream:
Florian Weimer
added a comment - - edited I made a glibc test build with a getenv function that is thread-safe in more cases:
https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
Install it using:
dnf update --nogpgcheck --repofrompath=RHEL-42410,https://people.redhat.com/~fweimer/1fAXIchZ0ZbC/glibc-2.39-17.el10.0.0.testfix.1.RHEL42410/
This is still a preview, some further enhancements are needed to avoid false negative results with concurrent unsetenv , and the documentation updates need to be written.
A more complete patch has been submitted upstream:
[PATCH] stdlib: Make getenv thread-safe in more cases
Thanks! Right, so there are these two threads that are competing:
Thread 16 (Thread 0x7fbec19bc640 (LWP 2063)): #0 futex_wait (futex_word=0x7fbe9c008d90, expected=2, private=0) at ../sysdeps/nptl/futex-internal.h:146 #1 __GI___lll_lock_wait (futex=futex@entry=0x7fbe9c008d90, private=0) at lowlevellock.c:49 #2 0x00007fbec4ec0be9 in lll_mutex_lock_optimized (mutex=0x7fbe9c008d90) at pthread_mutex_lock.c:48 #3 ___pthread_mutex_lock (mutex=0x7fbe9c008d90) at pthread_mutex_lock.c:128 #4 0x00007fbec5722cb8 in g_rec_mutex_lock (mutex=mutex@entry=0x7fbec57c2220 <g_variant_type_info_lock>) at ../glib/gthread-posix.c:397 #5 0x00007fbec5726017 in g_variant_type_info_unref (info=0x55987f058250) at ../glib/gvarianttypeinfo.c:868 #6 0x00007fbec5719fa4 in g_variant_unref (value=0x55987efc1680) at ../glib/gvariant-core.c:798 #7 0x00007fbec5718f59 in g_variant_iter_free (iter=0x7fbe9800c350) at ../glib/gvariant.c:3096 #8 g_variant_iter_free (iter=0x7fbe9800c350) at ../glib/gvariant.c:3092 #9 0x00007fbec5908f75 in g_settings_schema_key_init (key=key@entry=0x7fff89921000, schema=<optimized out>, name=name@entry=0x7fbec51b1e88 "cycle-group-backward") at ../gio/gsettingsschema.c:1336 #10 0x00007fbec590daea in g_settings_get_value (settings=settings@entry=0x55987f0622f0, key=key@entry=0x7fbec51b1e88 "cycle-group-backward") at ../gio/gsettings.c:1203 #11 0x00007fbec590f13f in g_settings_get_strv (settings=settings@entry=0x55987f0622f0, key=key@entry=0x7fbec51b1e88 "cycle-group-backward") at ../gio/gsettings.c:2183 #12 0x00007fbec50db2e6 in meta_prefs_add_keybinding (name=0x7fbec51b1e88 "cycle-group-backward", settings=0x55987f0622f0, action=<optimized out>, flags=<optimized out>) at ../src/core/prefs.c:1975 #13 0x00007fbec51ab60f in meta_prefs_add_keybinding (name=0x7fbec51b1e88 "cycle-group-backward", settings=<optimized out>, action=META_KEYBINDING_ACTION_CYCLE_GROUP_BACKWARD, flags=(META_KEY_BINDING_BUILTIN | META_KEY_BINDING_IS_REVERSED)) at ../src/core/keybindings.c:991 #14 add_keybinding_internal (display=<optimized out>, name=0x7fbec51b1e88 "cycle-group-backward", settings=<optimized out>, flags=(META_KEY_BINDING_BUILTIN | META_KEY_BINDING_IS_REVERSED), action=META_KEYBINDING_ACTION_CYCLE_GROUP_BACKWARD, func=0x7fbec50cc080 <handle_cycle>, data=2, user_data=0x0, free_data=0x0) at ../src/core/keybindings.c:953 #15 add_builtin_keybindings.isra.0 (settings=settings@entry=0x55987f0622f0, keybindings=keybindings@entry=0x7fbec525e6e0 <COMMON_KEYBINDINGS>, n_keybindings=n_keybindings@entry=81, display=<optimized out>) at ../src/core/keybindings.c:990 #16 0x00007fbec50c0bc1 in init_builtin_key_bindings (display=0x55987f05da50) at ../src/core/keybindings.c:3165 #17 meta_display_init_keys (display=0x55987f05da50) at ../src/core/keybindings.c:3240 #18 meta_display_new (context=0x55987d11a7c0, error=0x7fff899213c0) at ../src/core/display.c:971 #19 0x00007fbec50d233b in meta_context_start (context=context@entry=0x55987d11a7c0, error=error@entry=0x7fff899213c0) at ../src/core/meta-context.c:487 #20 0x0000559842fd3039 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:701
Thread 1 (Thread 0x7fbe39c006c0 (LWP 2192)): #0 __GI_getenv (name=name@entry=0x7fbec36ea140 "FONTCONFIG_SYSROOT") at getenv.c:31 #1 0x00007fbec36bf2d3 in IA__FcConfigCreate () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fccfg.c:196 #2 0x00007fbec36cb1b5 in FcInitLoadOwnConfig (config=0x0) at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:82 #3 0x00007fbec36c6b5d in FcInitLoadOwnConfigAndFonts (config=0x0) at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:170 #4 IA__FcInitLoadConfigAndFonts () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:184 #5 FcConfigEnsure () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fccfg.c:96 #6 0x00007fbec36cb44d in FcConfigInit () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fccfg.c:122 #7 IA__FcInit () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:193 #8 0x00007fbec3710065 in init_in_thread (task_data=0x55987f057250) at ../pango/pangofc-fontmap.c:874 #9 fc_thread_func (data=0x55987f056fc0) at ../pango/pangofc-fontmap.c:964 #10 0x00007fbec56ffdf2 in g_thread_proxy (data=0x7fbe980096e0) at ../glib/gthread.c:835 #11 0x00007fbec4ebd812 in start_thread (arg=<optimized out>) at pthread_create.c:447 #12 0x00007fbec4f2d27c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
meta_context_start sets several environment variables at the same time fontconfig is trying to see if it runs in sysroot. Presumably, there's a realloc involved and that's what's causing the crash.
Ray Strode
added a comment - - edited Thanks! Right, so there are these two threads that are competing:
Thread 16 ( Thread 0x7fbec19bc640 (LWP 2063)):
#0 futex_wait (futex_word=0x7fbe9c008d90, expected=2, private =0) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x7fbe9c008d90, private =0) at lowlevellock.c:49
#2 0x00007fbec4ec0be9 in lll_mutex_lock_optimized (mutex=0x7fbe9c008d90) at pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=0x7fbe9c008d90) at pthread_mutex_lock.c:128
#4 0x00007fbec5722cb8 in g_rec_mutex_lock (mutex=mutex@entry=0x7fbec57c2220 <g_variant_type_info_lock>) at ../glib/gthread-posix.c:397
#5 0x00007fbec5726017 in g_variant_type_info_unref (info=0x55987f058250) at ../glib/gvarianttypeinfo.c:868
#6 0x00007fbec5719fa4 in g_variant_unref (value=0x55987efc1680) at ../glib/gvariant-core.c:798
#7 0x00007fbec5718f59 in g_variant_iter_free (iter=0x7fbe9800c350) at ../glib/gvariant.c:3096
#8 g_variant_iter_free (iter=0x7fbe9800c350) at ../glib/gvariant.c:3092
#9 0x00007fbec5908f75 in g_settings_schema_key_init (key=key@entry=0x7fff89921000, schema=<optimized out>, name=name@entry=0x7fbec51b1e88 "cycle-group-backward" ) at ../gio/gsettingsschema.c:1336
#10 0x00007fbec590daea in g_settings_get_value (settings=settings@entry=0x55987f0622f0, key=key@entry=0x7fbec51b1e88 "cycle-group-backward" ) at ../gio/gsettings.c:1203
#11 0x00007fbec590f13f in g_settings_get_strv (settings=settings@entry=0x55987f0622f0, key=key@entry=0x7fbec51b1e88 "cycle-group-backward" ) at ../gio/gsettings.c:2183
#12 0x00007fbec50db2e6 in meta_prefs_add_keybinding (name=0x7fbec51b1e88 "cycle-group-backward" , settings=0x55987f0622f0, action=<optimized out>, flags=<optimized out>) at ../src/core/prefs.c:1975
#13 0x00007fbec51ab60f in meta_prefs_add_keybinding (name=0x7fbec51b1e88 "cycle-group-backward" , settings=<optimized out>, action=META_KEYBINDING_ACTION_CYCLE_GROUP_BACKWARD, flags=(META_KEY_BINDING_BUILTIN | META_KEY_BINDING_IS_REVERSED)) at ../src/core/keybindings.c:991
#14 add_keybinding_internal (display=<optimized out>, name=0x7fbec51b1e88 "cycle-group-backward" , settings=<optimized out>, flags=(META_KEY_BINDING_BUILTIN | META_KEY_BINDING_IS_REVERSED), action=META_KEYBINDING_ACTION_CYCLE_GROUP_BACKWARD, func=0x7fbec50cc080 <handle_cycle>, data=2, user_data=0x0, free_data=0x0) at ../src/core/keybindings.c:953
#15 add_builtin_keybindings.isra.0 (settings=settings@entry=0x55987f0622f0, keybindings=keybindings@entry=0x7fbec525e6e0 <COMMON_KEYBINDINGS>, n_keybindings=n_keybindings@entry=81, display=<optimized out>) at ../src/core/keybindings.c:990
#16 0x00007fbec50c0bc1 in init_builtin_key_bindings (display=0x55987f05da50) at ../src/core/keybindings.c:3165
#17 meta_display_init_keys (display=0x55987f05da50) at ../src/core/keybindings.c:3240
#18 meta_display_new (context=0x55987d11a7c0, error=0x7fff899213c0) at ../src/core/display.c:971
#19 0x00007fbec50d233b in meta_context_start (context=context@entry=0x55987d11a7c0, error=error@entry=0x7fff899213c0) at ../src/core/meta-context.c:487
#20 0x0000559842fd3039 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:701
Thread 1 ( Thread 0x7fbe39c006c0 (LWP 2192)):
#0 __GI_getenv (name=name@entry=0x7fbec36ea140 "FONTCONFIG_SYSROOT" ) at getenv.c:31
#1 0x00007fbec36bf2d3 in IA__FcConfigCreate () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fccfg.c:196
#2 0x00007fbec36cb1b5 in FcInitLoadOwnConfig (config=0x0) at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:82
#3 0x00007fbec36c6b5d in FcInitLoadOwnConfigAndFonts (config=0x0) at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:170
#4 IA__FcInitLoadConfigAndFonts () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:184
#5 FcConfigEnsure () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fccfg.c:96
#6 0x00007fbec36cb44d in FcConfigInit () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fccfg.c:122
#7 IA__FcInit () at /usr/src/debug/fontconfig-2.15.0-4.el10.x86_64/src/fcinit.c:193
#8 0x00007fbec3710065 in init_in_thread (task_data=0x55987f057250) at ../pango/pangofc-fontmap.c:874
#9 fc_thread_func (data=0x55987f056fc0) at ../pango/pangofc-fontmap.c:964
#10 0x00007fbec56ffdf2 in g_thread_proxy (data=0x7fbe980096e0) at ../glib/gthread.c:835
#11 0x00007fbec4ebd812 in start_thread (arg=<optimized out>) at pthread_create.c:447
#12 0x00007fbec4f2d27c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
meta_context_start sets several environment variables at the same time fontconfig is trying to see if it runs in sysroot. Presumably, there's a realloc involved and that's what's causing the crash.
Lei Yang
added a comment - Hello rhn-engineering-rstrode
http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/section2/coredump/RHEL-42410/thread-all-info
Please review above file.
Lei Yang
added a comment - Hello rhn-engineering-rstrode
http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/section2/coredump/RHEL-42410/thread-all-info
Please review above file. Ray Strode
added a comment - note it would be useful to get a
(gdb) thread apply all bt full
Discussed it with rhn-support-codonell. This is now priority Major because it is expected we work around this in glibc for RHEL 10 GA.
Upstream development work is still ongoing, and further patches are expected.