Description of problem: running firefox with youtube and terminal session Version-Release number of selected component: systemd-resolved-256.11-1.fc41 Additional info: reporter: libreport-2.17.15 type: CCpp reason: systemd-resolved killed by SIGSEGV journald_cursor: s=8373c0216ffa42f7bc156a3ab3b2a51e;i=7ca9;b=ce3de8d6e6c449e9b452f5a97adf8dc4;m=116cd3a27;t=62d27a68881e5;x=56f13e26502e47fe executable: /usr/lib/systemd/systemd-resolved cmdline: /usr/lib/systemd/systemd-resolved cgroup: 0::/system.slice/systemd-resolved.service rootdir: / uid: 193 kernel: 6.12.11-200.fc41.x86_64 package: systemd-resolved-256.11-1.fc41 runlevel: N 5 backtrace_rating: 3 comment: running firefox with youtube and terminal session Truncated backtrace: Thread no. 1 (16 frames) #0 ?? #1 uc_canonical_decomposition at uninorm/canonical-decomposition.c:73 #3 u32_normalize at uninorm/u-normalize-internal.h:86 #4 _tr46 at /usr/src/debug/libidn2-2.3.7-2.fc41.x86_64/lib/lookup.c:395 #5 idn2_lookup_u8 at /usr/src/debug/libidn2-2.3.7-2.fc41.x86_64/lib/lookup.c:552 #6 dns_name_apply_idna at ../src/shared/dns-domain.c:1303 #7 dns_question_new_address at ../src/resolve/resolved-dns-question.c:340 #8 vl_method_resolve_hostname at ../src/resolve/resolved-varlink.c:379 #9 varlink_dispatch_method at ../src/shared/varlink.c:1424 #10 varlink_process at ../src/shared/varlink.c:1497 #11 defer_callback at ../src/shared/varlink.c:2904 #12 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:4263 #13 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:4844 #14 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:4905 #15 sd_event_loop at ../src/libsystemd/sd-event/sd-event.c:4927 #16 run at ../src/resolve/resolved.c:92
Created attachment 2074868 [details] File: proc_pid_status
Created attachment 2074869 [details] File: maps
Created attachment 2074870 [details] File: limits
Created attachment 2074871 [details] File: environ
Created attachment 2074872 [details] File: open_fds
Created attachment 2074873 [details] File: mountinfo
Created attachment 2074874 [details] File: os_info
Created attachment 2074875 [details] File: cpuinfo
Created attachment 2074876 [details] File: core_backtrace
Created attachment 2074877 [details] File: exploitable
Created attachment 2074878 [details] File: dso_list
Created attachment 2074879 [details] File: backtrace
The name that's being resolved (waa-pa.clients6.google.com) is pure ASCII. I'm pretty sure libidn2 shouldn't choke on it.
The report says that the older libidn2-2.3.7-2.fc41.x86_64 is being used, while there meanwhile is libidn2-2.3.8-1.fc41.x86_64. Is this segmentation fault somehow reproducible?
(In reply to Robert Scheck from comment #14) > The report says that the older libidn2-2.3.7-2.fc41.x86_64 is being used, > while there meanwhile is libidn2-2.3.8-1.fc41.x86_64. > > Is this segmentation fault somehow reproducible? I doubt it is. I think it was a glitch: a random memory corruption somewhere. I moved it to you just because you might have known something I didn't.