Bug#817763: Please backport pinentry-gtk2 to jessie-backports
Package: pinentry-gtk2 Severity: wishlist pinentry > 0.9.6 supports copy/paste. This makes it more usable with KeePassX, so we'd like to ship pinentry-gtk2 > 0.9.6 in Tails [1]. It would be great if someone would backport it. [1] https://labs.riseup.net/code/issues/11099
Bug#820223: tor: Tor doesn't start at start-up
Package: tor Version: 0.2.9.8-2 Severity: normal Dear Maintainer, I encountered the same problem reported here. On my system, I configured Tor to automatically start on boot via `systemctl enable tor@default`. But during boot, the start of the service fails repeatedly with these log messages: [notice] Tor 0.2.9.8 (git-a0df013ea241b026) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0c and Zlib 1.2.8. [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". [notice] Read configuration file "/etc/tor/torrc". [warn] Unparseable address in hidden service port configuration. [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details. [err] Reading config failed--see warnings above. When starting the service manually with `systemctl start tor@default`, the service starts fine. I took a look at the systemd unit files and added `network-online.target` to the `After=` line of `/lib/systemd/system/tor@default.service`. This fixed the problem for me, after rebooting Tor started without errors. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tor depends on: ii adduser 3.115 ii init-system-helpers 1.46 ii libc62.24-8 ii libevent-2.0-5 2.0.21-stable-2.1 ii libseccomp2 2.3.1-2.1 ii libssl1.11.1.0c-2 ii libsystemd0 232-8 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-4 Versions of packages tor recommends: ii logrotate3.11.0-0.1 ii tor-geoipdb 0.2.9.8-2 ii torsocks 2.2.0-1 Versions of packages tor suggests: pn apparmor-utils pn mixmaster ii obfs4proxy 0.0.7-1 pn obfsproxy pn socat pn tor-arm ii torbrowser-launcher 0.2.6-3 -- Configuration Files: /etc/tor/torrc changed: HiddenServiceDir /var/lib/tor/ssh/ HiddenServicePort 22 127.0.0.1:22 HiddenServiceDir /var/lib/tor/xmpp/ HiddenServicePort 5222 jabber.[redacted]:5222
Bug#1070674: gnome-settings-daemon: No oom-kill notifications
Package: gnome-settings-daemon
Version: 46.0-1+b3
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: segfa...@riseup.net
The systemd OOM notification functionality of gnome-settings-daemon is broken
on Debian. On Fedora, a notification is shown when a process is OOM-killed. On
Debian, it only works after applying the attached patch, which calls the
Subscribe() method of org.freedesktop.systemd1.Manager. It's not clear to me
why it works without the patch on Fedora.
I also created an issue and MR upstream, but upstream is waiting on a
confirmation that the systemd behavior (not sending the PropertiesChanged
signal unless Subscribe() was called) is expected.
Upstream issue: https://gitlab.gnome.org/GNOME/gnome-settings-
daemon/-/issues/790
Upstream MR: https://gitlab.gnome.org/GNOME/gnome-settings-
daemon/-/merge_requests/366
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gnome-settings-daemon depends on:
ii gnome-settings-daemon-common46.0-1
ii gsettings-desktop-schemas 46.0-1
ii libasound2t64 1.2.11-1+b1
ii libc6 2.37-19
ii libcairo2 1.18.0-3+b1
ii libcanberra-gtk3-0t64 [libcanberra-gtk3-0] 0.30-12.2+b2
ii libcanberra00.30-16
ii libcolord2 1.4.7-1+b1
ii libcups2t64 2.4.7-1.2+b1
ii libfontconfig1 2.15.0-1.1
ii libgck-2-2 4.2.0-5
ii libgcr-4-4 4.2.0-5
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3
ii libgeoclue-2-0 2.7.1-2+b1
ii libgeocode-glib-2-0 3.26.3-6+b2
ii libglib2.0-0t64 2.78.4-7
ii libgnome-desktop-3-20t6444.0-5
ii libgtk-3-0t64 3.24.41-4
ii libgudev-1.0-0 238-5
ii libgweather-4-0t64 4.4.2-1
ii libmm-glib0 1.22.0-3+b1
ii libnm0 1.46.0-2
ii libnotify4 0.8.3-1+b1
ii libp11-kit0 0.25.3-5
ii libpam-systemd [logind] 255.5-1
ii libpango-1.0-0 1.52.1+ds-1
ii libpangocairo-1.0-0 1.52.1+ds-1
ii libpolkit-gobject-1-0 124-2
ii libpulse-mainloop-glib0 16.1+dfsg1-5
ii libpulse0 16.1+dfsg1-5
ii libspa-0.2-bluetooth1.0.5-1+b3
ii libsystemd0 255.5-1
ii libupower-glib3 1.90.3-1
ii libwacom9 2.10.0-2
ii libwayland-client0 1.22.0-2.1+b1
ii libx11-62:1.8.7-1+b1
ii libxext62:1.3.4-1+b1
ii libxfixes3 1:6.0.0-2+b1
ii libxi6 2:1.8.1-1
ii pipewire-audio 1.0.5-1
Versions of packages gnome-settings-daemon recommends:
ii iio-sensor-proxy 3.5-1+b2
ii pipewire-audio 1.0.5-1
ii pkexec 124-2
ii x11-xserver-utils 7.7+10+b1
Versions of packages gnome-settings-daemon suggests:
pn usbguard
-- no debconf information
diff --git a/plugins/housekeeping/gsd-systemd-notify.c
b/plugins/housekeeping/gsd-systemd-notify.c
index 39984f5d..57421cc5 100644
--- a/plugins/housekeeping/gsd-systemd-notify.c
+++ b/plugins/housekeeping/gsd-systemd-notify.c
@@ -204,6 +204,22 @@ on_bus_gotten (GDBusConnection *obj,
}
self->session = con;
+
+// Subscribe to systemd events by calling Subscribe on
+// org.freedesktop.systemd1.Manager
+g_dbus_connection_call (self->session,
+"org.freedesktop.systemd1",
+"/org/freedesktop/systemd1",
+"org.freedesktop.systemd1.Manager",
+"Subscribe",
+NULL,
+G_VARIANT_TYPE ("()"),
+G_DBUS_CALL_FLAGS_NONE,
+-1,
+NULL,
+NU
Bug#1031814: linux-image-6.0.0-0.deb11.6-amd64: Fix issues from DSA-5324-1
Package: linux-image-6.0.0-0.deb11.6-amd64 Version: 6.0.12-1~bpo11+1 Severity: normal Dear Maintainer, This version of the kernel is vulnerable to security issues from DSA-5324-1. Is an upload of a version which fixes those issues planned for bullseye-backports? -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.0.0-0.deb11.6-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.0.0-0.deb11.6-amd64 recommends: ii apparmor 3.0.8-2+b1 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.0.0-0.deb11.6-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 pn linux-doc-6.0
Bug#1065659: supermin ignores dependencies of which the t64 version is installed
Package: supermin Version: 5.2.2-3 Severity: important X-Debbugs-Cc: segfa...@riseup.net After installing recent package updates, libguestfs fails to start guestfsd inside a supermin appliance. The error it fails with is: guestfsd: error while loading shared libraries: librpm.so.9: cannot open shared object file: No such file or directory The source of the problem seems to be that librpm9t64 is installed on my host. That package does provide a librpm.so.9, but supermin doesn't copy it to the appliance. The librpm9 package is also missing in the verbose output (printed by -v -v) of supermin. If I install librpm9 instead of librpm9t64, the librpm.so.9 is copied to the appliance. When I do that, guestfsd fails with the next missing dependency, libcurl.so.4, which is provided by libcurl4t64 on my host (so it seems to be the same issue with the t64 version being ignored again). I would have expected supermin to either use the libraries it finds on my host or, if it notices that they are incompatible, that it fails with an error instead of ignoring the dependencies. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.7-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages supermin depends on: ii apt 2.7.13+b1 ii cpio 2.15+dfsg-1 ii e2fsprogs 1.47.0-2.3+b1 ii libc6 2.37-15.1 ii libcom-err2t64 [libcom-err2] 1.47.0-2.3+b1 ii libext2fs2t64 [libext2fs2]1.47.0-2.3+b1 Versions of packages supermin recommends: ii linux-image-amd64 6.7.7-1 supermin suggests no packages. -- no debconf information
Bug#810865: infinoted: Add init script and service file
I was about to prepare a patch for an infinoted systemd service myself. Please apply this patch. Cheers
Bug#878706: isenkram: Packagekit transaction flags incorrect
Package: isenkram Version: 0.36 Tags: patch The packagekit transaction flags are currently used incorrectly. See the below patch which fixes this bug. --- >From a56e8119cee2e72201582905309644b24b08eb3d Mon Sep 17 00:00:00 2001 From: segfault Date: Mon, 16 Oct 2017 01:37:55 +0200 Subject: [PATCH] Fix incorrect transaction flags Packagekit expects the transaction flags as a bit field, but in the python bindings the flags are an enumeration. --- isenkramd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/isenkramd b/isenkramd index a3bdd39..3d700fe 100755 --- a/isenkramd +++ b/isenkramd @@ -232,7 +232,7 @@ class PackageKitInstaller(object): # Start package installation results = client.install_packages( -packagekit.TransactionFlagEnum.ONLY_TRUSTED, package_ids + [None], +1 << packagekit.TransactionFlagEnum.ONLY_TRUSTED, package_ids + [None], None, self.progress_callback, self) self._assert_success(results)
Bug#701903: Issue incorrectly tagged fixed-upstream
This bug was tagged as fixed-upstream, but the upstream issue wasn't actually fixed, it was merely moved to GitLab. The old upstream issue: http://bugzilla.gnome.org/show_bug.cgi?id=679622 The new upstream issue (still open): https://gitlab.gnome.org/GNOME/gimp/issues/535
Bug#701903: Issue incorrectly tagged fixed-upstream
Simon McVittie: > You mentioned Bugzilla #679622, but that looks like an unrelated bug > (which was also migrated to Gitlab, this time as GNOME/gimp#412). Right, copied the wrong link, sorry about that.
Bug#659593: coreutils: *** glibc detected *** tac: double free or corruption (top): 0x000000000061b030 ***
Package: coreutils Version: 8.5-1 Severity: important $ tac *>/dev/null *** glibc detected *** tac: double free or corruption (top): 0x0061b030 *** === Backtrace: = /lib/libc.so.6(+0x71bd6)[0x7fb3b04d9bd6] /lib/libc.so.6(cfree+0x6c)[0x7fb3b04de94c] tac[0x402660] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fb3b0486c8d] tac[0x401999] === Memory map: 0040-00417000 r-xp 08:01 49671 /usr/bin/tac 00617000-00618000 rw-p 00017000 08:01 49671 /usr/bin/tac 00618000-0063b000 rw-p 00:00 0 [heap] 7fb3abdea000-7fb3abe0 r-xp 08:01 114705 /lib/libgcc_s.so.1 7fb3abe0-7fb3abfff000 ---p 00016000 08:01 114705 /lib/libgcc_s.so.1 7fb3abfff000-7fb3ac00 rw-p 00015000 08:01 114705 /lib/libgcc_s.so.1 7fb3ac00-7fb3ac021000 rw-p 00:00 0 7fb3ac021000-7fb3b000 ---p 00:00 0 7fb3b01d6000-7fb3b0468000 r--p 08:01 49303 /usr/lib/locale/locale-archive 7fb3b0468000-7fb3b05c1000 r-xp 08:01 114732 /lib/libc-2.11.3.so 7fb3b05c1000-7fb3b07c ---p 00159000 08:01 114732 /lib/libc-2.11.3.so 7fb3b07c-7fb3b07c4000 r--p 00158000 08:01 114732 /lib/libc-2.11.3.so 7fb3b07c4000-7fb3b07c5000 rw-p 0015c000 08:01 114732 /lib/libc-2.11.3.so 7fb3b07c5000-7fb3b07ca000 rw-p 00:00 0 7fb3b07ca000-7fb3b07e8000 r-xp 08:01 114722 /lib/ld-2.11.3.so 7fb3b0979000-7fb3b09ba000 rw-p 00:00 0 7fb3b09db000-7fb3b09de000 rw-p 00:00 0 7fb3b09e4000-7fb3b09e7000 rw-p 00:00 0 7fb3b09e7000-7fb3b09e8000 r--p 0001d000 08:01 114722 /lib/ld-2.11.3.so 7fb3b09e8000-7fb3b09e9000 rw-p 0001e000 08:01 114722 /lib/ld-2.11.3.so 7fb3b09e9000-7fb3b09ea000 rw-p 00:00 0 7fffe5fe3000-7fffe5ff7000 rw-p 00:00 0 [stack] 7fffe5fff000-7fffe600 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Аварийный останов -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32.36-228-scalaxy (SMP w/16 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages coreutils depends on: ii libacl1 2.2.49-4 Access control list shared library ii libattr1 1:2.4.44-2 Extended attribute shared library ii libc6 2.11.3-2 Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1 SELinux runtime shared libraries coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#797890: ruby 1.9.3p194 segfault on debian stable 7.x
Package: ruby Version: 1:1.9.3 Severity: important Tags: upstream -- System Information: Debian Release: 7.8 APT prefers oldstable APT policy: (500, 'oldstable'), (20, 'stable'), (10, 'oldstable'), (1, 'oldstable-updates'), (1, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-37-pve (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby depends on: ii ruby1.9.1 1.9.3.194-8.1+deb7u2 ruby recommends no packages. Versions of packages ruby suggests: pn ri ii ruby1.8-dev [ruby-dev] 1.8.7.358-7.1+deb7u1 -- no debconf information 1) I setup OpenStreetMap API-server: https://github.com/openstreetmap/openstreetmap-website 2) start with debug (It is crashed with, or without --debugger flag): bundle exec rails server --debugger &> /root/osm_rails_crash.log 2) Then I start OsmBot https://github.com/progserega/osmbot , which processing many data in automatic mode. 3) After some time (3-5 hours) - ruby crash (in attachment - full log): var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:113: [BUG] Segmentation fault ruby 1.9.3p194 (2012-04-20 revision 35410) [i486-linux] -- Control frame information --- c:0016 p:0017 s:0088 b:0088 l:0007dc d:87 BLOCK /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:113 c:0015 p: s:0085 b:0085 l:84 d:84 FINISH c:0014 p: s:0083 b:0083 l:82 d:82 CFUNC :each c:0013 p:0017 s:0080 b:0080 l:79 d:79 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0012 p:0017 s:0075 b:0075 l:74 d:74 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0011 p:0017 s:0070 b:0070 l:69 d:69 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0010 p:0017 s:0065 b:0065 l:64 d:64 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0009 p:0017 s:0060 b:0060 l:59 d:59 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0008 p:0017 s:0055 b:0055 l:54 d:54 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0007 p:0017 s:0050 b:0050 l:49 d:49 METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31 c:0006 p:0587 s:0045 b:0045 l:0007dc d:0007dc METHOD /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:112 c:0005 p:0257 s:0030 b:0030 l:29 d:29 METHOD /usr/lib/ruby/1.9.1/webrick/httpserver.rb:138 c:0004 p:0393 s:0020 b:0020 l:19 d:19 METHOD /usr/lib/ruby/1.9.1/webrick/httpserver.rb:94 c:0003 p:0126 s:0009 b:0009 l:000144 d:08 BLOCK /usr/lib/ruby/1.9.1/webrick/server.rb:191 c:0002 p: s:0004 b:0004 l:03 d:03 FINISH c:0001 p: s:0002 b:0002 l:01 d:01 TOP -- Ruby level backtrace information /usr/lib/ruby/1.9.1/webrick/server.rb:191:in block in start_thread' /usr/lib/ruby/1.9.1/webrick/httpserver.rb:94:inrun' /usr/lib/ruby/1.9.1/webrick/httpserver.rb:138:in service' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:112:inservice' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:in each' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:ineach' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:in each' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:ineach' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:in each' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:ineach' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:in each' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/body_proxy.rb:31:ineach' /var/lib/gems/1.9.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:113:in `block in service' -- C level backtrace information --- /usr/lib/libruby-1.9.1.so.1.9(+0x15e5c3) [0xb76ee5c3] /usr/lib/libruby-1.9.1.so.1.9(+0x507ff) [0xb75e07ff] /usr/lib/libruby-1.9.1.so.1.9(rb_bug+0x40) [0xb75e0dd0] /usr/lib/libruby-1.9.1.so.1.9(+0xf8a1c) [0xb7688a1c] [0xb77ae600] /usr/lib/libruby-1.9.1.so.1.9(+0x64c19) [0xb75f4c19] /usr/lib/libruby-1.9.1.so.1.9(+0x163891) [0xb76f3891] /usr/lib/libruby-1.9.1.so.1.9(+0x15267d) [0xb76e267d] /usr/lib/libruby-1.9.1.so.1.9(+0x153280) [0xb76e3280] /usr/lib/libruby-1.9.1.so.1.9(rb_yield+0x180) [0xb76e9b80] /usr/lib/libruby-1.9.1.so.1.9(rb_ary_each+0x54) [0xb75b02e4] /usr/lib/libruby-1.9.1.so.1.9(+0x148d45) [0xb76d8d45] /usr/lib/libruby-1.9.1.so.1.9(+0x157de7) [0xb76e7de7] /usr/lib/libruby-1.9.1.so.1.9(+0x14eb4e) [0xb76deb4e] /usr/lib/libruby-1.9.1.so.1.9(+0x153280) [0xb76e3280] /usr/lib/libruby-1.9.1.so.1.9(+0x153f5f) [0xb76e3f5f] /usr/lib/libruby-1.9.1.so.1.9(+0x164c03) [0xb76f4c03] /usr/lib/libruby-1.9.1.so.1.9(+0x164cdd) [0xb76f4cdd] /lib/i386-linux-gnu/libpthread.so.0(+0x5954) [0xb757c954] /lib/i386-linux-gnu/libc.so.6(clone+0x5e) [0xb7497c1e]
Bug#503213: apache2: Apache child is segfaulting due to a call to memcpy().
Package: apache2 Version: 2.2.3-4+etch5 Severity: important Configuration needed for this issue: Apache2 MPM Worker installed mod_disk_ache activated on the Host/VirtualHost URI mod_proxy_ajp serving this URI with ProxyPass mod_deflate compressing the resource served from this URI Configuration snipet: ProxyPass/uri ajp://tomcat-host:8009/uri ProxyPassReverse /uri ajp://tomcat-host:8009/uri AddOutpFilterByType DEDEFLATE text/html Header append Vary User-Agent env=!dont-vary CacheEnable disk /uri To reproduce the bug, run the following wget pattern : wget -d http://myapache/uri \ --header=Accept-Encoding:gzip,deflate \ --header=User-Agent:Mozilla/5 \ --header=Cache-Control: max-age=0 The HTTP header that trigger the bug is the Cache-Control: max-age=0. A workaround is to tell the cache to ignore CacheControl statement, but it is far from an optimal solution. I've attached the stack trace produced by running : [EMAIL PROTECTED] gdb /usr/sbin/apache2 [...] (gdb) run -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1493375328 (LWP 11202)] 0x2afba65c7fa0 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x2afba65c7fa0 in memcpy () from /lib/libc.so.6 #1 0x2afba5ee4655 in apr_file_read () from /usr/lib/libapr-1.so.0 #2 0x2afba5ee6ed5 in apr_file_read_full () from /usr/lib/libapr-1.so.0 #3 0x2afba7e5135b in ?? () from /usr/lib/apache2/modules/mod_disk_cache.so #4 0x2afba7b462e2 in cache_select () from /usr/lib/apache2/modules/mod_cache.so #5 0x2afba7b457bb in ?? () from /usr/lib/apache2/modules/mod_cache.so #6 0x00432f72 in ap_run_quick_handler () #7 0x00441df1 in ap_process_request () #8 0x0043f40c in ap_register_input_filter () #9 0x00439a21 in ap_run_process_connection () #10 0x00446346 in ap_graceful_stop_signalled () #11 0x2afba6340f1a in start_thread () from /lib/libpthread.so.0 #12 0x2afba661d5d2 in clone () from /lib/libc.so.6 #13 0x in ?? () (gdb) exit This bug appears when using AJP13/Compression/Caching with Apache2 on Debian Etch amd64. It can't be reproduce on the i386 package. --System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: x86_64 (amd64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages apache2 depends on: ii apache2-mpm-worker 2.2.3-4+etch5 High speed threaded model for Apac apache2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#787081: php5: segfault when using SoapClient::__setSoapHeader
Source: php5 Version: 5.6.7+dfsg-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? We use a SOAP connection with partners * What exactly did you do (or not do) that was effective (or ineffective)? The problem appeared once after migration of php in wheezy to version 5.4.39-0+deb7u1 (https://www.debian.org/security/2015/dsa-3198) and it was fixed. Following migration to Jessie and php 5.6.7+dfsg-1 the problem reappeared. * What was the outcome of this action? When I launch a SOAP connection which use __setSoapHeader I get a segmentation fault * What outcome did you expect instead? I expected to connect *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.18.11-vs2.3.7.4-beng (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
