Bug#1073827: Acknowledgement (chromium: Chromium exits with SIGSEGV resulting in "Restore pages" dialog on next start)
Seems to be duplicate of 1073378 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073378). [http://cetitec.com/_resources/app/css/img/signature_logo.png] CETITEC GmbH Mannheimer Str. 17 D-75179 Pforzheim https://www.cetitec.com Sitz der Gesellschaft / Location: Pforzheim, Germany Amtsgericht / Registry Court: Mannheim, Germany, HRB 715734 Geschäftsführer / Chief Executive Officer: Dr. Michael Back Hinweis / Note: Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese Mail. Das unerlaubte Speichern, Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet! This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is not allowed!
Bug#1073827: chromium: Chromium exits with SIGSEGV resulting in "Restore pages" dialog on next start
Package: chromium Version: 126.0.6478.56-1~deb12u1 Severity: important Dear Maintainer, Chromium process is killed with a SIGSEGV starting with 126.0.6478.56-1~deb12u1. * What led up to the situation? The crash appears to started happening with upgrade from 121.0.6167.139-1~deb12u1 to 126.0.6478.56-1~deb12u1. * What exactly did you do (or not do) that was effective (or ineffective)? Simply stopping the chromium windows (either from window manager, or using the Exit menu item) results in the chromium process to be killed by SIGSEGV. * What was the outcome of this action? The process is killed by SIGSEGV. After restarting the browser asks to restore the pages opened previously complaining not being shutdown properly. Running "DEBUGINFOD_URLS=https://debuginfod.debian.net chromium --debug" produces this upon exiting: Thread 6 "ThreadPoolForeg" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeea006c0 (LWP 9403)] 0x5f453b7c in ?? () (gdb) bt #0 0x5f453b7c in () #1 0x1ddc06ab4f00 in () #2 0x1ddc097471c0 in () #3 0x7fffee9fd770 in () #4 0x5f47135f in () #5 0x7fffee9fd870 in () #6 0x1ddc02811c50 in () #7 0x1ddc097471c0 in () #8 0x in () Running and exiting chromium with a clean profile still crashes and prints something similar but equally unusable: Thread 1 "chromium" received signal SIGSEGV, Segmentation fault. 0x5c5f2e3c in ?? () (gdb) bt #0 0x5c5f2e3c in () #1 0x7fffcf70 in () #2 0x57d3d20c in () #3 0x0002 in () #4 0x0070 in () #5 0x7fffcf88 in () #6 0x299400020568 in () #7 0x6365 in data_start () #8 0x299400c40a50 in () #9 0x299400020440 in () #10 0xfffc in () #11 0x7fffcfc0 in () #12 0x57d37e6a in () #13 0x7fffcfc0 in () #14 0x299400b21c30 in () #15 0x5c6fe9e0 in () #16 0xa170406ef4a88800 in () #17 0x299400b21c30 in () #18 0x6365 in data_start () #19 0x299400020440 in () #20 0xfffc in () #21 0x7fffd000 in () #22 0x5f011f78 in () #23 0x631ddee8 in () #24 0x299400b21c30 in () #25 0x6365 in data_start () #26 0x299400c40a50 in () #27 0x299400979400 in () #28 0x299400979410 in () #29 0x7fffd020 in () #30 0x5f01209e in () #31 0x631ddee8 in () #32 0x299400020440 in () #33 0x7fffd080 in () #34 0x5f00bd04 in () #35 0x in () * What outcome did you expect instead? At least not having to restore the open pages. Not crashing at all would be a welcome extra, as I sometimes record core dumps system-wide (for unrelated reasons) and would like to have less noise to analyze. Thanks, Alex Riesen -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.5 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii chromium-common126.0.6478.56-1~deb12u1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-02.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-0 2.46.0-5 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libcups2 2.4.2-3+deb12u5 ii libdav1d6 1.0.0-2+deb12u1 ii libdbus-1-31.14.10-1~deb12u1 ii libdouble-conversion3 3.2.1-1 ii libdrm22.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libflac12 1.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgbm122.3.6-1+deb12u1 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libharfbuzz-subset06.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libjpeg62-turbo1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip11.1-8+deb12u1 ii libnspr4 2:4.35-1 ii libnss32:3.87.1-1 ii libopenh264-7 2.3.1+dfsg-3 ii libopenjp2-7 2.5.0-2 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-161.6.39-2 ii libpulse0 16
Bug#993432: libspice-server1: spice-vdagentd discards monitor configuration from host which breaks guest display resize
Package: libspice-server1 Version: 0.14.3-2.1 Severity: normal Dear Maintainer, * What led up to the situation? I noticed that guest systems (Ubuntu 18.x and 20.x) of a QEMU VM stopped updating their internal display configuration (resizing the display after resizing the host window) with upgrade from Buster to Bullseye (0.14.0 -> 0.14.3-2.1). * What exactly did you do (or not do) that was effective (or ineffective)? Initially, I verified that the QEMU host configuration included correct options to use QXL display and SPICE protocol. AFAIK, it does: -vga qxl \ -device virtio-serial-pci \ -spice unix,addr=qemu-spice.sock,disable-ticketing \ -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ -chardev spicevmc,id=spicechannel0,name=vdagent I also verified the guest systems still run spice-vdagent. They do. * What was the outcome of this action? I noticed that the guest systems started reporting an error, which I don't remember seeing before: Sep 01 09:50:04 GUEST spice-vdagentd[11881]: invalid message size for VDAgentMonitorsConfig >From the vdagentd code, it seems that it will discard the configuration of the host window for the guests display if the message size isn't exactly what it expects. This results in a scaled image of the guest display, which is not what I expect for the VMs using SPICE protocol. * What outcome did you expect instead? I expected the guest system to re-configure its graphics output to fit the window on the host, as it did before. * Additional information I tried instrumenting the vdagentd code to figure out why it considers the monitor configuration invalid and noticed that the virtio messages are larger than the code expects: ... invalid message size for VDAgentMonitorsConfig (392 != 328, monitors 16, sizeof 8) 392 above is `message_header->size` from src/vdagentd/vdagentd.c, while 328 is the expected message size calculated in the same function. Indeed, making the abort condition to allow for larger messages allows the messages to be interpreted and the decoded monitors configuration seems to be correct. Guest display re-configuration with that works as expected (at least on visual inspection). The problem now is that I'd rather avoid re-compiling spice-vdagent in all guest images (of which there are many). I would like to fix it in the host code instead, since it seemed to work before the upgrade. Regards, Alex -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.13 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libspice-server1 depends on: ii libc6 2.31-13 ii libglib2.0-02.66.8-1 ii libgstreamer-plugins-base1.0-0 1.18.4-2 ii libgstreamer1.0-0 1.18.4-2.1 ii libjpeg62-turbo 1:2.0.6-4 ii liblz4-11.9.3-2 ii libopus01.3.1-0.1 ii liborc-0.4-01:0.4.32-1 ii libpixman-1-0 0.40.0-1 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.1 1.1.1k-1+deb11u1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libspice-server1 recommends: ii gstreamer1.0-libav 1.18.4-3 ii gstreamer1.0-plugins-base 1.18.4-2 ii gstreamer1.0-plugins-good 1.18.4-2 Versions of packages libspice-server1 suggests: ii gstreamer1.0-plugins-ugly 1.18.4-2 -- no debconf information
Bug#944369: edid-decode crashes with division-by-zero for incorrect EDID
Bernhard Übelacker, Tue, Nov 19, 2019 00:03:41 +0100: > Your attached output of the current upstream might > point to this commit [1]. ... > [1] > https://git.linuxtv.org/edid-decode.git/commit/?id=0da30bd8cbe8c023236f22ad2a8477a1f0b96679 Looks like it. > But to be sure either you should attach a copy of > your input file, or if that is now wanted, > a backtrace ... It's an in-development version of the Linux kernel driver for Analog Digital HDMI decoder ADV7482 with hard-coded EDID (was never in mainline). The EDID itself (with the errors causing div-by-0) is in the variable g_edid_data of the file adv748x-hdmi.c (https://github.com/renesas-rcar/linux-bsp/blob/v4.14/rcar-3.7.3/drivers/media/i2c/adv748x/adv748x-hdmi.c) Extracted from the file above: $ curl https://raw.githubusercontent.com/renesas-rcar/linux-bsp/v4.14/rcar-3.7.3/drivers/media/i2c/adv748x/adv748x-hdmi.c | sed -ne '/__u8 g_edid_data/,/^};/p' | gcc -E -xc - | sed -e '/^\(#\|$\)/d' -e 's/\(0x[0-9A-Fa-f][0-9a-fA-F]\)u/\1/g' | sed -e 1d -e '$d' It looks like this: 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x0C, 0x01, 0x03, 0x80, 0x50, 0x2D, 0x78, 0x0A, 0x0D, 0xC9, 0xA0, 0x57, 0x47, 0x98, 0x27, 0x12, 0x48, 0x4C, 0x20, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A, 0x80, 0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C, 0x45, 0x00, 0xDC, 0x0B, 0x11, 0x00, 0x00, 0x1E, 0x8C, 0x0A, 0xD0, 0x8A, 0x20, 0xE0, 0x2D, 0x10, 0x10, 0x3E, 0x96, 0x00, 0x58, 0xC2, 0x21, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x7C, 0x00, 0x4D, 0x59, 0x20, 0x48, 0x44, 0x54, 0x56, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, 0x2E, 0x06, 0x00, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x75, 0x02, 0x03, 0x1E, 0x40, 0x83, 0x7F, 0x40, 0x05, 0x40, 0x48, 0x10, 0x05, 0x04, 0x01, 0x02, 0x06, 0x15, 0x11, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0x1B, 0x00, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD8, which crashes the old edid-decode: $ apt-get source edid-decode=0.1~git20180813.b2da1516-1 $ debuild -- binary $ gdb --args edid-decode ../edid.hex ... Program received signal SIGFPE, Arithmetic exception. (gdb) bt #0 0x837d in detailed_block (x=x@entry=0x55567b56 "", in_extension=in_extension@entry=1) at edid-decode.c:1026 #1 0xbf80 in parse_cta (x=0x55567af0 "\002\003\036@\203\177@\005@H\020\005\004\001\002\006\025\021") at edid-decode.c:2304 #2 parse_extension (x=0x55567af0 "\002\003\036@\203\177@\005@H\020\005\004\001\002\006\025\021") at edid-decode.c:2505 #3 edid_from_file (from_file=, to_file=, to_file@entry=0x0, out_fmt=, out_fmt@entry=OUT_FMT_DEFAULT) at edid-decode.c:3165 #4 0x744b in main (argc=2, argv=0x7fffe358) at edid-decode.c:3380 (gdb) Regards, Alex
Bug#944369: edid-decode crashes with division-by-zero for incorrect EDID
Package: edid-decode Version: 0.1~git20191108.3a6108a75be356-1 Severity: wishlist Dear Maintainer, I was trying to validate the EDID table of an HDMI device. The data were incorrect (the device also wasn't recognized correctly) and when given to edid-decode to analyze the table the program is killed by SIGFPE caused by a division-by-zero: $ edid-decode edid Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 00 00 00 00 00 00 00 00 01 0c version: 01 03 basic params:80 50 2d 78 0a chroma info: 0d c9 a0 57 47 98 27 12 48 4c established: 20 00 00 standard:01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1:02 3a 80 18 71 38 2d 40 58 2c 45 00 dc 0b 11 00 00 1e descriptor 2:8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 58 c2 21 00 00 18 descriptor 3:00 00 00 7c 00 4d 59 20 48 44 54 56 0a 20 20 20 20 20 descriptor 4:00 00 00 00 00 00 00 0a 2e 06 00 0a 20 20 20 20 20 20 extensions: 01 checksum:75 EDID version: 1.3 Manufacturer: @@@ Model 0 Serial Number 0 Digital display Maximum image size: 80 cm x 45 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6250, 0.3398 Green: 0.2802, 0.5947 Blue: 0.1552, 0.0703 White: 0.2832, 0.2978 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz Standard timings supported: Detailed mode: Clock 148.500 MHz, 476 mm x 267 mm 1920 2008 2052 2200 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync VertFreq: 60 Hz, HorFreq: 67500 Hz Detailed mode: Clock 27.000 MHz, 600 mm x 450 mm 720 736 798 858 hborder 0 480 489 495 525 vborder 0 -hsync -vsync VertFreq: 59 Hz, HorFreq: 31468 Hz Unknown monitor description type 124 Manufacturer-specified data, tag 0 Has 1 extension blocks Checksum: 0x75 (valid) CTA extension block Extension version: 3 26 bytes of CTA data Speaker allocation data block Speaker map: FL/FR - Front Left/Right LFE - Low Frequency Effects FC - Front Center BL/BR - Back Left/Right BC - Back Center FLC/FRC - Front Left/Right of Center RLC/RRC - Rear Left/Right of Center SiL/SiR - Side Left/Right TpBL/TpBR - Top Back Left/Right BtFL/BtBR - Bottom Front Left/Right Video data block Video data block VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz VIC 1 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz VIC 2 720x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 27.000 MHz VIC 6 1440x480i@60Hz 4:3 HorFreq: 15734 Hz Clock: 27.000 MHz VIC 21 1440x576i@50Hz 4:3 HorFreq: 15625 Hz Clock: 27.000 MHz VIC 17 720x576@50Hz 4:3 HorFreq: 31250 Hz Clock: 27.000 MHz Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Unknown tag 0, length 0 (raw 00) Basic audio support 0 native detailed modes Detailed mode: Clock 82.240 MHz, 544 mm x 32 mm 32 32 554 64 hborder 32 3840 3842 3842 7680 vborder 32 -hsync -vsync analog composite field sequential L/R VertFreq: 167 Hz, HorFreq: 1285000 Hz Detailed mode: Clock 82.240 MHz, 544 mm x 32 mm 32 32 554 64 hborder 32 256 258 258 3072 vborder 32 -hsync -vsync analog composite field sequential L/R VertFreq: 418 Hz, HorFreq: 1285000 Hz Floating point exception I would expect a sensible error message. Please note that the table is handled by the current upstream verison of the edid-decode, which can parse the data and give the error in this case: ... Invalid Detailed Timings: Horizontal Active/Blanking 32/32 Vertical Active/Blanking 0/0 Checksum: 0xd8 (valid) EDID block does NOT conform to EDID 1.3! Missing name descriptor Missing monitor ranges EDID block does not conform: Bad year of manufacture Detailed blocks filled with garbage Manufacturer name
Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements
Charles Plessy, Wed, Jul 03, 2019 14:59:42 +0200: > Le Mon, Jul 01, 2019 at 03:52:47PM +0200, Alex Riesen a écrit : > > > > diff --git a/update-mime b/update-mime > > Thanks a lot. I suppose you do not mind your name and email appearing > in the commit or in the package's changelog ? ... I don't. Glad I could help! Regards, Alex
Bug#931340: dirmngr goes into endless loop if keyserver responses with http error 503
DBG: Using TLS library: GNUTLS 3.6.6
dirmngr[28324.0]: DBG: http.c:connect_server: trying
name='internal.corp.company.com' port=11371
dirmngr[28324.0]: DBG: dns: resolve_dns_name(internal.corp.company.com): Success
dirmngr[28324.0]: DBG: http.c:1899:socket_new: object 0x55dc0c265d00 for fd
6 created
dirmngr[28324.0]: DBG: http.c:request:
dirmngr[28324.0]: DBG: >> GET
/pks/lookup?op=index=mr=inter...@email-address.com HTTP/1.0\r\n
dirmngr[28324.0]: DBG: >> Host: internal.corp.company.com:11371\r\n
dirmngr[28324.0]: DBG: http.c:request-header:
dirmngr[28324.0]: DBG: >> \r\n
dirmngr[28324.0]: DBG: http.c:response:
dirmngr[28324.0]: DBG: >> HTTP/1.0 503 Service Not Available\r\n
dirmngr[28324.0]: http.c:RESP: 'Content-Type: text/html'
dirmngr[28324.0]: http.c:RESP: 'Content-Length: 369'
dirmngr[28324.0]: http.c:RESP: 'Connection: close'
dirmngr[28324.0]: http.c:RESP: 'Date: Tue, 02 Jul 2019 13:15:31 GMT'
dirmngr[28324.0]: http.c:RESP: 'Server: lighttpd/1.4.43'
dirmngr[28324.0]: http.c:RESP: ''
dirmngr[28324.0]: error accessing
'http://internal.corp.company.com:11371/pks/lookup?op=index=mr=internal%40email-address%2Ecom':
http status 503
dirmngr[28324.0]: selecting a different host due to a 503 (Service Unavailable)
dirmngr[28324.0]: DBG: Using TLS library: GNUTLS 3.6.6
dirmngr[28324.0]: DBG: http.c:connect_server: trying
name='internal.corp.company.com' port=11371
dirmngr[28324.0]: DBG: dns: resolve_dns_name(internal.corp.company.com): Success
dirmngr[28324.0]: DBG: http.c:1899:socket_new: object 0x55dc0c16b560 for fd
6 created
dirmngr[28324.0]: DBG: http.c:request:
dirmngr[28324.0]: DBG: >> GET
/pks/lookup?op=index=mr=inter...@email-address.com HTTP/1.0\r\n
dirmngr[28324.0]: DBG: >> Host: internal.corp.company.com:11371\r\n
dirmngr[28324.0]: DBG: http.c:request-header:
dirmngr[28324.0]: DBG: >> \r\n
dirmngr[28324.0]: DBG: http.c:response:
dirmngr[28324.0]: DBG: >> HTTP/1.0 503 Service Not Available\r\n
dirmngr[28324.0]: http.c:RESP: 'Content-Type: text/html'
dirmngr[28324.0]: http.c:RESP: 'Content-Length: 369'
dirmngr[28324.0]: http.c:RESP: 'Connection: close'
dirmngr[28324.0]: http.c:RESP: 'Date: Tue, 02 Jul 2019 13:15:31 GMT'
dirmngr[28324.0]: http.c:RESP: 'Server: lighttpd/1.4.43'
dirmngr[28324.0]: http.c:RESP: ''
dirmngr[28324.0]: error accessing
'http://internal.corp.company.com:11371/pks/lookup?op=index=mr=internal%40email-address%2Ecom':
http status 503
* What was the outcome of this action?
The last request/response repeats endlessly.
* What outcome did you expect instead?
To abort the request. While the 503 error is often assumed to be temporary, it
is more often than not takes some time to resolve itself. Just blindly retrying
on the keyserver may cause the dirmngr to hang up.
On my system I plugged this problem with the patch below. I don't think this is
acceptable for everyone. May be a configuration option per-keyserver would be
better?
Regards,
Alex
commit c64f17c751d30df9be0943ad185075313954fdaf
Author: Alex Riesen
Date: Tue Jul 2 15:29:12 2019 +0200
Make http error 503 (Service unavailable) fatal for a keyserver
While the error is considered temporary, it is unlikely to be
resolve itself soon and marking the host dead is a better solution
than to retry quickly.
diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c
index 68d2064..c22ee0a 100644
--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -1353,13 +1353,13 @@ handle_send_request_error (ctrl_t ctrl, gpg_error_t
err, const char *request,
switch (http_status)
{
case 502: /* Bad Gateway */
+ case 503: /* Service Unavailable */
log_info ("marking host dead due to a %u (%s)\n",
http_status, http_status2string (http_status));
if (mark_host_dead (request) && *tries_left)
retry = 1;
break;
- case 503: /* Service Unavailable */
case 504: /* Gateway Timeout*/
log_info ("selecting a different host due to a %u (%s)",
http_status, http_status2string (http_status));
-- System Information:
Debian Release: 9.9
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.1.15 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dirmngr depends on:
ii adduser3.115
ii gpgconf2.2.12-1~bpo9+1
ii libassuan0 2.5.2-1
ii libc6 2.28-2
ii libgcrypt201.8.4-5
ii libgnutls303.6.6-2
ii libgpg-error0 1.26-2
ii libksba8 1.3.5-2
ii libldap-2.4-2 2.4.44+dfsg-5+deb9u2
ii libnpth0 1.3-1
ii lsb-base
Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements
Charles Plessy, Mon, Jul 01, 2019 15:26:03 +0200:
> Le Mon, Jul 01, 2019 at 09:05:36AM +0200, Alex Riesen a écrit :
> >
> > elsif (m/MimeType=(.*)/i) {
> > - push @types, split(/;/, $1);
> > + push @types, grep {length>0}
> > split(/\s*;\s*/, $1);
>
> Do you think it would make sense to throw a warning on stderr when such
> a broken entry is found ? In that case, would you have time to propose
> an updated patch ?
Of course. Like the below, perhaps? (I still filter them out).
Regards,
Alex
diff --git a/update-mime b/update-mime
index d27b8a9..55495ee 100755
--- a/update-mime
+++ b/update-mime
@@ -157,7 +157,10 @@ sub ReadDesktopEntries
$exec .= " %s" if ($exec !~ m/%s/);
}
elsif (m/MimeType=(.*)/i) {
- push @types, split(/;/, $1);
+ my $err = 0;
+ push @types, grep { if (length>0) {1}
else {++$err;0} }
+split(/\s*;\s*/, $1);
+ print STDERR "Warning: $file:$.:
ignoring empty entries in MimeType\n" if $err;
}
}
if (!defined($exec) || !scalar(@types)) {
Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements
Package: mime-support
Version: 3.60
Severity: minor
Dear Maintainer,
I noticed a strange entry in /etc/mailcap:
application/x-ext-cb7; evince %s; test=test -n "$DISPLAY"
; evince %s; test=test -n "$DISPLAY"
application/oxps; evince %s; test=test -n "$DISPLAY"
After a bit of investigation, it turned out that generation of the entry has
been triggered by an empty item in evince.desktop (evince 3.22.1-3+deb9u1) file:
MimeType=application/pdf;application/x-bzpdf;application/x-gzpdf;application/x-xzpdf;application/x-ext-pdf;application/postscript;application/x-bzpostscript;application/x-gzpostscript;image/x-eps;image/x-bzeps;image/x-gzeps;application/x-ext-ps;application/x-ext-eps;application/x-dvi;application/x-bzdvi;application/x-gzdvi;application/x-ext-dvi;image/vnd.djvu;image/vnd.djvu+multipage;application/x-ext-djv;application/x-ext-djvu;image/tiff;application/x-cbr;application/x-cbz;application/x-cb7;application/x-ext-cbr;application/x-ext-cbz;application/vnd.comicbook+zip;application/x-ext-cb7;;application/oxps;application/vnd.ms-xpsdocument;
Correcting the desktop file to have only full types in the list obviously
fixed the mailcap, but I wonder if instead of correcting desktop files (or in
addition to) the update-mime should filter out such entries from MimeType?
For instance (diff against 3.62 from unstable, fits 3.60 too):
diff --git a/update-mime b/update-mime
index d27b8a9..be4187f 100755
--- a/update-mime
+++ b/update-mime
@@ -157,7 +157,7 @@ sub ReadDesktopEntries
$exec .= " %s" if ($exec !~ m/%s/);
}
elsif (m/MimeType=(.*)/i) {
- push @types, split(/;/, $1);
+ push @types, grep {length>0}
split(/\s*;\s*/, $1);
}
}
if (!defined($exec) || !scalar(@types)) {
Regards,
Alex
-- System Information:
Debian Release: 9.9
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.1.15 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
mime-support depends on no packages.
Versions of packages mime-support recommends:
ii bzip2 1.0.6-8.1
ii file 1:5.30-1+deb9u2
ii xz-utils 5.2.2-1.2+b1
mime-support suggests no packages.
-- no debconf information
Bug#871638: rustc panics when trying to list the target cpus if the current directory does not exist anymore
Package: rustc
Version: 1.14.0+dfsg1-3
Severity: normal
Dear Maintainer,
just trying to run the commands below (with or without RUST_BACKTRACE) causes
rustc to panic. The removal of the directory was originally not intentional,
so a crash for such harmless command was a bit of surprise.
$ mkdir dir
$ cd dir
$ rm -rf ../dir
$ RUST_BACKTRACE=1 rustc -C target-cpu=help
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report:
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error
{ repr: Os { code: 2, message: "No such file or directory" } }',
src/libcore/result.rs:837
stack backtrace:
1: 0x7f7d23970dda -
2: 0x7f7d2398305f -
3: 0x7f7d2397f8a5 -
4: 0x7f7d2397ffc7 -
std::panicking::rust_panic_with_hook::h109e116a3a861224
5: 0x7f7d2397fe54 -
6: 0x7f7d2397fd79 - std::panicking::begin_panic_fmt::h26713cea9bce3ab0
7: 0x7f7d2397fd07 - rust_begin_unwind
8: 0x7f7d239cb41d - core::panicking::panic_fmt::hcfbb59eeb7f27f75
9: 0x7f7d20be63d3 -
10: 0x7f7d20d6ebcc - rustc::session::build_session_::h7a3559f2373a5d05
11: 0x7f7d20d6dd7e -
rustc::session::build_session_with_codemap::h68bc7bcd2f34eee4
12: 0x7f7d20d6d72c - rustc::session::build_session::h437fda3c327a8bde
13: 0x7f7d23d26030 - >::no_input::h8047df7741757d1c
14: 0x7f7d23d21d27 - rustc_driver::run_compiler::hafe7bbfedf95a825
15: 0x7f7d23c57378 -
16: 0x7f7d2398ae0a - __rust_maybe_catch_panic
17: 0x7f7d23c76fa8 -
18: 0x7f7d2397eb74 -
19: 0x7f7d1ed4f493 - start_thread
20: 0x7f7d23645afe - __clone
21:0x0 -
Sadly, the backtrace is not improved by install the debug symbols.
-- System Information:
Debian Release: 9.1
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.12.4 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages rustc depends on:
ii binutils 2.28-5
ii gcc 4:6.3.0-4
ii libc6 2.24-11+deb9u1
ii libc6-dev [libc-dev] 2.24-11+deb9u1
ii libjs-jquery 3.1.1-2
ii libstd-rust-dev 1.14.0+dfsg1-3
Versions of packages rustc recommends:
ii rust-gdb 1.14.0+dfsg1-3
ii rust-lldb 1.14.0+dfsg1-3
Versions of packages rustc suggests:
ii rust-doc 1.14.0+dfsg1-3
-- no debconf information
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests
Package: perl-base
Version: 5.24.1-3+deb9u1
Severity: normal
Dear Maintainer,
when I run the test suite (Git (the VCS, master branch), the perl binary
sometimes crashes in one of its tests. I used the commands below to reproduce
the problem (just let it run, it'll crash eventually):
$ git clone git://git.kernel.org/pub/scm/git/git.git && cd git
$ make USE_LIBPCRE2=YesPlease (requires curl-dev and openssl-dev, I think...)
$ cd t (the test suite)
$ ulimit -c unlimited
$ rm -rf 'trash directory.t9128-git-svn-cmd-branch'
$ while ./t9128-git-svn-cmd-branch.sh -d -i
do
echo; echo
rm -rf 'trash directory.t9128-git-svn-cmd-branch'
done
...
not ok 3 - git svn branch tests
#
# git svn branch a &&
# base=$(git rev-parse HEAD:) &&
# test $base = $(git rev-parse remotes/origin/a:) &&
# git svn branch -m "created branch b blah" b &&
# test $base = $(git rev-parse remotes/origin/b:) &&
# test_must_fail git branch -m "no branchname" &&
# git svn branch -n c &&
# test_must_fail git rev-parse remotes/origin/c &&
# test_must_fail git svn branch a &&
# git svn branch -t tag1 &&
# test $base = $(git rev-parse remotes/origin/tags/tag1:) &&
# git svn branch --tag tag2 &&
# test $base = $(git rev-parse remotes/origin/tags/tag2:) &&
# git svn tag tag3 &&
# test $base = $(git rev-parse remotes/origin/tags/tag3:) &&
# git svn tag -m "created tag4 foo" tag4 &&
# test $base = $(git rev-parse remotes/origin/tags/tag4:) &&
# test_must_fail git svn tag -m "no tagname" &&
# git svn tag -n tag5 &&
# test_must_fail git rev-parse remotes/origin/tags/tag5 &&
# test_must_fail git svn tag tag1
#
$ gdb /usr/bin/perl './trash directory.t9128-git-svn-cmd-branch/core'
...
(gdb) bt full
#0 0x00b2ce983b10 in Perl_sv_clear (my_perl=my_perl@entry=0xb2cefdf010,
orig_sv=orig_sv@entry=0xb2d00807e8) at sv.c:6582
stash =
type = 9
sv_type_details =
iter_sv = 0x0
next_sv = 0x0
sv = 0xb2d00807e8
hash_index = 0
#1 0x00b2ce983da0 in Perl_sv_free2 (my_perl=my_perl@entry=0xb2cefdf010,
sv=sv@entry=0xb2d00807e8, rc=) at sv.c:6954
No locals.
#2 0x00b2ce8fd8a5 in S_SvREFCNT_dec (sv=0xb2d00807e8,
my_perl=0xb2cefdf010) at inline.h:166
rc =
#3 Perl_gp_free (my_perl=my_perl@entry=0xb2cefdf010, gv=gv@entry=0xb2d0080938)
at gv.c:2568
file_hek =
hv =
io = 0xb2d00807e8
form = 0x0
sv =
cv = 0x0
av = 0x0
gp =
attempts = 100
#4 0x00b2ce983b74 in Perl_sv_clear (my_perl=my_perl@entry=0xb2cefdf010,
orig_sv=orig_sv@entry=0xb2d00e92c0) at sv.c:6585
stash =
type = 9
sv_type_details =
iter_sv = 0x0
next_sv = 0x0
sv = 0xb2d0080938
hash_index = 0
#5 0x00b2ce983da0 in Perl_sv_free2 (my_perl=my_perl@entry=0xb2cefdf010,
sv=0xb2d00e92c0, rc=) at sv.c:6954
No locals.
#6 0x00b2ce972ad2 in S_SvREFCNT_dec (sv=,
my_perl=0xb2cefdf010) at inline.h:166
rc =
#7 S_hv_delete_common (hash=, d_flags=68, k_flags=, klen=, key=, keysv=,
hv=0xb2cefdf010, my_perl=0xb2d007db68) at hv.c:1279
xhv =
first_entry =
stash =
entry = 0xb2d00e4828
keysv_hek =
mro_changes =
sv =
oentry = 0xb2d007db68
is_utf8 = false
masked_flags =
gv =
#8 Perl_hv_common (my_perl=my_perl@entry=0xb2cefdf010,
hv=hv@entry=0xb2cfff4e10, keysv=, key=,
key@entry=0x0, klen=, klen@entry=0, flags=,
flags@entry=0, action=68, val=0x0, hash=) at hv.c:397
xhv =
entry =
oentry =
sv =
is_utf8 = false
masked_flags =
return_svp = 0
keysv_hek = 0x0
#9 0x00b2ce9aca1f in Perl_pp_delete (my_perl=0xb2cefdf010) at pp.c:5061
_p =
sv =
mark = 0xb2cf00fed8
origmark = 0
hv = 0xb2cfff4e10
hvtype =
sp = 0xb2cf00fee0
gimme = 1 '\001'
discard = 4
#10 0x00b2ce976916 in Perl_runops_standard (my_perl=0xb2cefdf010) at
run.c:41
op =
#11 0x00b2ce8f4aee in Perl_call_sv (my_perl=my_perl@entry=0xb2cefdf010,
sv=0xb2cf546fd0, flags=flags@entry=45) at perl.c:2812
myop = {
op_next = 0x0,
op_sibling = 0x0,
op_ppaddr = 0x0,
op_targ = 0,
op_type = 0,
op_opt = 0,
op_slabbed = 0,
op_savefree = 0,
op_static = 0,
op_folded = 0,
op_moresib = 0,
op_spare = 0,
op_flags = 65 'A',
op_private = 0 '\000',
op_first = 0x0,
op_other = 0x7fffe7a15bf0
}
method_op = {
op_next = 0x7fffe7a15c78,
Bug#854484: hddtemp does not use the "airflow temperature" of the Samsung SSD drives
Package: hddtemp Version: 0.3-beta15-52 Severity: normal Dear Maintainer, please consider adding the line below to the /etc/hddtemp.db: "Samsung SSD 8.*" 190 C"Samsung SSD 850 EVO 2TB" The line enables hddtemp to report the "Airflow_Temperature_Cel" of the drives. The line has been tested with Samsung SSD 850 EVO and 840 PRO: $ tcpconnect 127.0.0.1:7634 |cat -v |/dev/sda|Samsung SSD 850 EVO 2TB|48|C||/dev/sdb|Samsung SSD 840 PRO Serise ^PM-^@|32|C||/dev/sdc|WDC WD7500BPKX-75HPJT0|38|C| For instance, smartctl reports the EVO 850 drive as: === START OF INFORMATION SECTION === Device Model: Samsung SSD 850 EVO 2TB Serial Number:S2RMNX0HC01587E LU WWN Device Id: 5 002538 c404c1c72 Firmware Version: EMT02B6Q User Capacity:2,000,398,934,016 bytes [2.00 TB] Sector Size: 512 bytes logical/physical Rotation Rate:Solid State Device Form Factor: 2.5 inches Device is:Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is:Tue Feb 7 16:26:40 2017 CET ... SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000Old_age Always - 25 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 4 177 Wear_Leveling_Count 0x0013 100 100 000Pre-fail Always - 0 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 056 054 000Old_age Always - 44 195 Hardware_ECC_Recovered 0x001a 200 200 000Old_age Always - 0 199 UDMA_CRC_Error_Count0x003e 100 100 000Old_age Always - 0 235 Unknown_Attribute 0x0012 100 100 000Old_age Always - 0 241 Total_LBAs_Written 0x0032 099 099 000Old_age Always - 3939988249 ... Regards, Alex -- System Information: Debian Release: 8.7 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.8 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages hddtemp depends on: ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18+deb8u7 ii lsb-base 4.1+Debian13+nmu1 hddtemp recommends no packages. Versions of packages hddtemp suggests: pn ksensors -- Configuration Files: /etc/hddtemp.db changed: "FUJITSU MHM2100AT" 0C "Fujitsu MHM2100AT" "HITACHI_DK228A-65" 0C "Hitachi DK228A-65" "IBM-DARA-212000" 0C "IBM Travelstar 12GN" "IBM-DTTA-35*" 0C "IBM Deskstar 16GP serie" "IBM-DJNA-35.*" 231 C "IBM Deskstar 25 GP serie" "IBM-DJNA-37.*" 231 C "IBM Deskstar 22 GXP serie" "IBM-DHEA-(34330|36480)"0C "IBM Deskstar 5 serie" "IBM-DHEA-(34331|36481|38451)" 0C "IBM Deskstar 8 serie" "IBM-DPTA-37.*" 231 C "IBM Deskstar 34GXP serie" "IBM-DPTA-35.*" 231 C "IBM Deskstar 37GP serie" "Maxtor 5(1024|1369|2049|2732|3073|4098)U(2|3|4|6|8)" 0C "Maxtor DiamondMax Plus 40" "Maxtor 5T0[24]0H[24]" 0C "Maxtor DiamondMax Plus 60" "Maxtor 94098U8"11 C "Maxtor DiamondMax 40 94098U8" "QUANTUM FIREBALLP AS40.0" 0 C "Quantum Fireball AS40" "QUANTUM FIREBALL CX10.2A" 0 C "Quantum Fireball CX10.2A" "SAMSUNG SW0434A" 0C "Samsung SW0434A" "SAMSUNG SV0432A" 0C "Samsung SV0432A" "SAMSUNG SV3002H" 0C "Samsung SpinPoint V30 serie" "Samsung SSD .*"190 C "Samsung SSD 850 EVO 2TB" "Seagate Technology 1275MB - ST31276A" 0C "Seagate ST31276A" "ST3412A" 0C "Seagate ST3412A" "ST38641A" 0C "Seagate ST38641A" "ST310210A"
