Bug 2257130
| Summary: | Coredump crash upon first client connexion | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stephane <fedora> |
| Component: | privoxy | Assignee: | Gwyn Ciesla <gwync> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 39 | CC: | cheese, fedora, gwync |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | privoxy-3.0.34-9.fc38 privoxy-3.0.34-9.fc39 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-02-01 01:24:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I can't reproduce this with default config, does it coredump with default config? Just to establish a baseline. Took the default Fedora config and added "forward-socks4a / 127.0.0.1:10000 ." :
#############################################
confdir /etc/privoxy
logdir /var/log/privoxy
filterfile default.filter
logfile logfile
listen-address 127.0.0.1:8118
toggle 1
enable-remote-toggle 0
enable-remote-http-toggle 0
enable-edit-actions 0
enforce-blocks 0
buffer-limit 4096
enable-proxy-authentication-forwarding 0
forwarded-connect-retries 0
accept-intercepted-requests 0
allow-cgi-request-crunching 0
split-large-forms 0
keep-alive-timeout 5
tolerate-pipelining 1
socket-timeout 300
forward-socks4a / 127.0.0.1:10000 .
#############################################
Here's the journald logs:
#######################################################################################################################################
Jan 13 17:54:24 fedora systemd-coredump[1164]: [🡕] Process 1140 (privoxy) of user 73 dumped core.
Module libcap.so.2 from rpm libcap-2.48-9.fc39.x86_64
Module libnss_systemd.so.2 from rpm systemd-254.7-1.fc39.x86_64
Module libnss_sss.so.2 from rpm sssd-2.9.3-1.fc39.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.42-1.fc39.2.x86_64
Module libz.so.1 from rpm zlib-1.2.13-4.fc39.x86_64
Module privoxy from rpm privoxy-3.0.34-5.fc39.x86_64
Stack trace of thread 1162:
#0 0x00007f223ff51834 __pthread_kill_implementation (libc.so.6 + 0x90834)
#1 0x00007f223feff8ee raise (libc.so.6 + 0x3e8ee)
#2 0x00007f223fee78ff abort (libc.so.6 + 0x268ff)
#3 0x00007f223fee87d0 __libc_message.cold (libc.so.6 + 0x277d0)
#4 0x00007f223ffe4d19 __fortify_fail (libc.so.6 + 0x123d19)
#5 0x00007f223ffe46d4 __chk_fail (libc.so.6 + 0x1236d4)
#6 0x00007f223ffe6119 __strlcpy_chk (libc.so.6 + 0x125119)
#7 0x000055ecdc02d587 socks4_connect (privoxy + 0x2e587)
#8 0x000055ecdc02d9fa forwarded_connect (privoxy + 0x2e9fa)
#9 0x000055ecdc02dec6 serve.lto_priv.0 (privoxy + 0x2eec6)
#10 0x00007f223ff4f897 start_thread (libc.so.6 + 0x8e897)
#11 0x00007f223ffd66fc __clone3 (libc.so.6 + 0x1156fc)
Stack trace of thread 1140:
#0 0x00007f223ffc8bcd __poll (libc.so.6 + 0x107bcd)
#1 0x000055ecdc0059b5 main (privoxy + 0x69b5)
#2 0x00007f223fee914a __libc_start_call_main (libc.so.6 + 0x2814a)
#3 0x00007f223fee920b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
#4 0x000055ecdc0063a5 _start (privoxy + 0x73a5)
ELF object binary architecture: AMD x86-64
#######################################################################################################################################
Here's the *gdb privoxy PID* details :
#######################################################################################################################################
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fd5636c0bcd in __GI___poll (fds=fds@entry=0x7fff19aafb70, nfds=nfds@entry=2, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29 return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) c
Continuing.
[New Thread 0x7fd5633986c0 (LWP 1272)]
Thread 2 "privoxy" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fd5633986c0 (LWP 1272)]
writev_for_fatal (total=45, niov=3, iov=0x7fd563396770, fd=2) at ../sysdeps/unix/sysv/linux/libc_fatal.c:31
31 && INTERNAL_SYSCALL_ERRNO (cnt) == EINTR);
(gdb) c
Continuing.
Thread 2 "privoxy" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) c
Continuing.
[Thread 0x7fd5633986c0 (LWP 1272) exited]
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
#######################################################################################################################################
With what curl call can you trigger this? Any tcp connection attempt will trigger the behavior. I tested with *curl ifconfig.co*, Firefox and dnf. Note: I did a dnf system-upgrade from Fedora 38 to Fedora 39 on the system. Upon reboot I encountered th segfault behavior. I could give it a test with a fresh Fedora 39 install if you think it may be relevant. Ah, I can now reproduce this, and it doesn't crash without that config line. Filed upstream bug. https://sourceforge.net/p/ijbswa/bugs/941/ Looks like it's already fixed upstream: https://www.privoxy.org/gitweb/?p=privoxy.git;a=commit;h=19d7684ca10f6c1279568aa19e9a9da2276851f1 Is it possible to backport this patch ? I'm not 100% sure it's available in the latest release either. Yes, thank you! I've tested it and it works. Update coming. FEDORA-2024-05e47dc59f has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-05e47dc59f FEDORA-2024-b2f3785e5f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b2f3785e5f FEDORA-2024-05e47dc59f has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-05e47dc59f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-05e47dc59f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-b2f3785e5f has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b2f3785e5f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b2f3785e5f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2024-b2f3785e5f has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-05e47dc59f has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. |
Jan 07 02:40:28 fedora systemd-coredump[1052]: Process 848 (privoxy) of user 73 dumped core. Module libcap.so.2 from rpm libcap-2.48-9.fc39.x86_64 Module libnss_systemd.so.2 from rpm systemd-254.7-1.fc39.x86_64 Module libnss_sss.so.2 from rpm sssd-2.9.3-1.fc39.x86_64 Module libpcre2-8.so.0 from rpm pcre2-10.42-1.fc39.2.x86_64 Module libz.so.1 from rpm zlib-1.2.13-4.fc39.x86_64 Module privoxy from rpm privoxy-3.0.34-5.fc39.x86_64 Stack trace of thread 1050: #0 0x00007f2442251834 __pthread_kill_implementation (libc.so.6 + 0x90834) #1 0x00007f24421ff8ee raise (libc.so.6 + 0x3e8ee) #2 0x00007f24421e78ff abort (libc.so.6 + 0x268ff) #3 0x00007f24421e87d0 __libc_message.cold (libc.so.6 + 0x277d0) #4 0x00007f24422e4d19 __fortify_fail (libc.so.6 + 0x123d19) #5 0x00007f24422e46d4 __chk_fail (libc.so.6 + 0x1236d4) #6 0x00007f24422e6119 __strlcpy_chk (libc.so.6 + 0x125119) #7 0x0000559604bc5587 socks4_connect (privoxy + 0x2e587) #8 0x0000559604bc59fa forwarded_connect (privoxy + 0x2e9fa) #9 0x0000559604bc5ec6 serve.lto_priv.0 (privoxy + 0x2eec6) #10 0x00007f244224f897 start_thread (libc.so.6 + 0x8e897) #11 0x00007f24422d66fc __clone3 (libc.so.6 + 0x1156fc) Stack trace of thread 848: #0 0x00007f24422c8bcd __poll (libc.so.6 + 0x107bcd) #1 0x0000559604b9d9b5 main (privoxy + 0x69b5) #2 0x00007f24421e914a __libc_start_call_main (libc.so.6 + 0x2814a) #3 0x00007f24421e920b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b) #4 0x0000559604b9e3a5 _start (privoxy + 0x73a5) ELF object binary architecture: AMD x86-64 Reproducible: Always Steps to Reproduce: 1. Start privoxy 2. Get a client to make a connection to it 3. Actual Results: See coredump stack in details Expected Results: No coredump Version: privoxy-3.0.34-5.fc39.x86_64 Config: forward-socks4a / 127.0.0.1:10000 . confdir /etc/privoxy logdir /var/log/privoxy actionsfile default.action # Main actions file actionsfile user.action # User customizations filterfile default.filter #logfile logfile #debug 4096 # Startup banner and warnings #debug 8192 # Errors - *we highly recommended enabling this* user-manual /usr/share/doc/privoxy/user-manual listen-address 127.0.0.1:20000 listen-address 100.64.3.10:20000 toggle 1 enable-remote-toggle 0 enable-edit-actions 0 enable-remote-http-toggle 0 buffer-limit 4096