Bug#942086: xpdf: Memory leak on large document (even w/ continuousView turned off)
Package: xpdf Version: 3.04-13 Severity: important I have a PDF document which seems to cause xpdf to leak memory as I advance through its pages. The severity of the leak seems to scale with the window size of xpdf, at least to some extent. I don't think this is the same bug as #926501, because I experience this with continuousView turned off. I checked /etc/xpdf/xpdfrc and ~/.xpdfrc and didn't find continuousView listed in either file. I verified that it seems to be disabled for me (to ensure it's not enabled by default) by checking the scrollbar: the scrollbar represents only the current page. In a 1276x2113 pixel window, xpdf starts by using 43752 KiB RSS while displaying the first page. If I advance through all pages of this document until I get to the end, RSS climbs to 2052816 KiB (2.0 GiB). In a 3840x2117 pixel window, xpdf starts on the same document using 55936 KiB RSS. After advancing to the end, it finishes using 3309660 KiB (3.2 GiB) RSS. I prefer xpdf because it's responsive and, until now, been very lightweight in my experience. However, this bug led me to compare xpdf's memory utilization performance to that of evince. On the same document, in a 3840x2117 pixel window, evince version 3.30.2-3 starts at 147144 KiB RSS. After advancing to the end (and allowing enough time for each page to render as I do so), evince finishes at 215876 KiB (211 MiB) RSS. I configured both xpdf and evince to scale each page to fit the window. The document I'm experiencing this is with https://www.andersonpower.com/content/dam/app/ecommerce/product-pdfs/CAT-PPMP.pdf . The version currently published there has these attributes: Size: 13529602 B (12.9 MiB) SHA256: 64079ffb140cca6c8747e9b0c9d88864098093b49e34a0e35399282467b09d73 HTTP Last-Modified: Tue, 10 Sep 2019 15:46:50 GMT PDF ModDate: Tue Sep 4 12:29:21 2018 PDT Page count: 124 I've made sure that this version of the document is available at the Internet Archive Wayback Machine at this URL: https://web.archive.org/web/20191010060834/https://www.andersonpower.com/content/dam/app/ecommerce/product-pdfs/CAT-PPMP.pdf I chose severity "important" because this is bad enough for me to stop using xpdf until the bug can be addressed. I lost 20 minutes to my system thrashing in swap (with xpdf alongside other big RAM users too). Thanks, -Jean-Paul -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xpdf depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libpaper1 1.1.28 ii libpoppler82 0.71.0-5 ii libstdc++68.3.0-6 ii libx11-6 2:1.6.7-1 ii libxm42.3.8-2 ii libxt61:1.1.5-1+b3 Versions of packages xpdf recommends: ii cups-bsd2.2.10-6+deb10u1 ii gsfonts-x11 0.26 ii poppler-data0.4.9-2 ii poppler-utils 0.71.0-5 ii sensible-utils 0.0.12 xpdf suggests no packages. -- no debconf information -- J.P. Larocque
Bug#939728: raspi3-firmware: serial console device for Raspberry Pi Model B rev 2 is incorrect
Package: raspi3-firmware
Version: 1.20190215-1
Dear Maintainer,
The script /etc/kernel/postinst.d/z50-raspi3-firmware selects which
serial device ther kernel should use as the console, and has a
specific check for Linux kernels 4.14 and later:
serial="ttyAMA0,115200"
kernelmajor=$(echo "${latest_kernel_basename}" | sed 's,^vmlinuz-,,g' | cut
-d. -f 1)
kernelminor=$(echo "${latest_kernel_basename}" | cut -d. -f 2)
if [ $kernelmajor -ge 4 ]; then
if [ $kernelminor -ge 14 ]; then
# Since Linux 4.14, /dev/ttyS1 is the UART on the pinheader.
serial="ttyS1,115200"
fi
fi
I have a Raspberry Pi Model B revision 2 which I made work with Buster
by copying the right DTB files into /boot/firmware (details reported
in a separate bug). I have linux-image-4.19.0-5-rpi installed, and no
other kernel version installed, but I get no serial output when I use
the cmdline.txt file generated by the postinst.d script, which
includes "console=tty0 console=ttyS1,115200". If I change it back to
ttyAMA0 by hand, or patch cmdline.txt in a later postinst.d script, I
do get serial output on boot and a login prompt once the system
finishes booting.
This is using physical pins 8 and 10 of header P1.
I don't know if this is because I'm using such an old board. Can you
please further limit the conditions which change the console to ttyS1?
I haven't looked into the question of when it should be ttyS1 and when
it should be ttyAMA0 (I just tried ttyAMA0 and it worked), so I'm
afraid I can't offer any patch which I know will be correct across all
boards.
Thanks for looking into this!
-- System Information:
Debian Release: 10.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv6l)
Kernel: Linux 4.19.0-5-rpi
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages raspi3-firmware depends on:
ii dosfstools 4.1-2
raspi3-firmware recommends no packages.
raspi3-firmware suggests no packages.
-- Configuration Files:
/etc/default/raspi3-firmware changed:
ROOTPART=UUID=7ffc98fc-1970-4289-a7ed-d89c844c3675
-- no debconf information
--
J.P. Larocque
Bug#939727: raspi3-firmware: copy DTB blobs for original Model B and other old boards
-updates'), (500, 'stable')
Architecture: armel (armv6l)
Kernel: Linux 4.19.0-5-rpi
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages raspi3-firmware depends on:
ii dosfstools 4.1-2
raspi3-firmware recommends no packages.
raspi3-firmware suggests no packages.
-- Configuration Files:
/etc/default/raspi3-firmware changed:
ROOTPART=UUID=7ffc98fc-1970-4289-a7ed-d89c844c3675
-- no debconf information
--
J.P. Larocque
#!/bin/sh
set -e
# Play nice when run under debconf.
exec &2
eval set -- "$DEB_MAINT_PARAMS"
# Only run on configure and remove to avoid unnecessary work.
case "$1" in
configure|remove)
;;
*)
exit 0
;;
esac
if ischroot ; then
true # chroot detected - skip mount point check
elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
true # virtualization detected - skip mount point check
elif ! mountpoint -q /boot/firmware; then
echo "raspi3-firmware: missing /boot/firmware, did you forget to mount it?"
>&2
exit 1
fi
latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort -V -r |
head -1)
if [ -z "$latest_kernel" ]; then
echo "raspi3-firmware: no kernel found in /boot/vmlinuz-*, cannot populate
/boot/firmware"
exit 0
fi
# Default configurations, overridable at /etc/default/raspi3-firmware
KERNEL="auto"
if [ -r /etc/default/raspi3-firmware ]; then
. /etc/default/raspi3-firmware
fi
# copy and rename the available device tree binaries
# the bootloader will pick the right device tree binary
# if it is named according to the system on chip family name
arch=$(dpkg --print-architecture)
if [ "arm64" = "$arch" ]; then
dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}/broadcom"
else
# there is no vendor subdirectory for armhf
dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
fi
if [ "$KERNEL" = "auto" ]; then
pi0_dtb=${dtb_path}/bcm2835-rpi-zero.dtb
pi0w_dtb=${dtb_path}/bcm2835-rpi-zero-w.dtb
pi1ap_dtb=${dtb_path}/bcm2835-rpi-a-plus.dtb
pi1b_dtb=${dtb_path}/bcm2835-rpi-b.dtb
pi1bp_dtb=${dtb_path}/bcm2835-rpi-b-plus.dtb
pi1cm_dtb=${dtb_path}/bcm2835-rpi-cm1-io1.dtb
[ -e "${pi0_dtb}" ] && cp "${pi0_dtb}" /boot/firmware/bcm2708-rpi-zero.dtb
[ -e "${pi0w_dtb}" ] && cp "${pi0w_dtb}"
/boot/firmware/bcm2708-rpi-zero-w.dtb
[ -e "${pi1ap_dtb}" ] && cp "${pi1ap_dtb}"
/boot/firmware/bcm2708-rpi-a-plus.dtb
[ -e "${pi1b_dtb}" ] && cp "${pi1b_dtb}" /boot/firmware/bcm2708-rpi-b.dtb
[ -e "${pi1bp_dtb}" ] && cp "${pi1bp_dtb}"
/boot/firmware/bcm2708-rpi-b-plus.dtb
[ -e "${pi1cm_dtb}" ] && cp "${pi1cm_dtb}" /boot/firmware/bcm2708-rpi-cm.dtb
fi
#!/bin/sh
exec /etc/kernel/postinst.d/"$(basename "$0")" "$@"
Bug#933857: solr-jetty: Jetty lacks necessary write permissions to /var/lib/solr/data/index/
stephan, thanks for tracking this down. I almost figured it out, and then I found that you already reported this bug. Your other bug report was also super helpful for me to get Solr working after my upgrade to Buster. On Sun, Aug 04, 2019 at 03:31:52PM +0200, beirer wrote: > The fix is also similar: > > Copy /lib/systemd/system/jetty9.service to /etc/systemd/system and modify > it by adding > > ReadWritePaths=/var/lib/solr/data > > to the # Security paragraph. I found that adding a file /etc/systemd/system/jetty9.service.d/override.conf (and making its parent directory, both via `systemctl edit jetty9`) with these contents allowed me to append to the ReadWritePaths list, overriding just the right part to get Solr to work under Jetty: - [Service] ReadWritePaths=/var/lib/solr/data/ - Debian Java Maintainers, is there a sensible way to ship a systemd override file like this with solr-jetty? (The right path for such a packaged override file might be under /lib/systemd/ somewhere, because I think /etc/systemd/ is reserved for user-made customizations.) -- J.P. Larocque
Bug#886090: solr-jetty: Doesn't work out-of-the-box anymore; required symlink is missing
Package: solr-jetty Version: 3.6.2+dfsg-10 Severity: normal Hi, I'm using Solr to provide full-text indexing services for Dovecot, which uses it to index e-mail bodies. I've only barely scratched the surface of Java, and know nothing about Java web application development or deployment. I installed Solr on my mail server when it was running Jessie or an earlier release of Debian. I seem to recall that the setup process at that point in time was pretty straightforward. Recreating the scenario on a fresh Jessie system now, I see that all I needed to do to get Jetty responding with Solr-generated responses was to install solr-jetty, edit /etc/default/jetty8 to set NO_START=0, and restart jetty8. When I upgraded my mail server to Debian Stretch, Solr stopped working. Jetty responded with status 404 instead: $ curl --verbose http://localhost:8080/solr/ * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 8080 (#0) > GET /solr/ HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 404 Not Found < Content-Type: text/html; charset=ISO-8859-1 < Cache-Control: must-revalidate,no-cache,no-store < Content-Length: 289 < Server: Jetty(9.2.21.v20170120) < Error 404 Not Found HTTP ERROR 404 Problem accessing /solr/. Reason: Not FoundPowered by Jetty:// * Curl_http_done: called premature == 0 * Connection #0 to host localhost left intact Because of my lack of experience with the Java and Jetty ecosystem, it was a confusing and frustrating process to get Solr working again. It seemed like the symlink /etc/jetty9/contexts/solr.xml -> ../../solr/solr-jetty.xml was supposed to be doing something, but it apparently wasn't. (On my Jessie test system, a similar symlink in /etc/jetty8/contexts/ seems to be the piece that configures Jetty for Solr.) It seems like some configuration methods changed between Jetty 8 (Jessie) and Jetty 9 (Stretch). Eventually, I found a helpful message on jetty-users [1], and a pointer to the right part of the Jetty documentation [2]. I created this symlink: $ sudo ln -s /etc/solr/solr-jetty.xml /var/lib/jetty9/webapps/solr.xml After restarting Jetty, Jetty responded to /solr URLs again, and Solr worked with my existing configuration and application as it did previously. If this symlink is always the right thing to do for an upgrade or a new installation, would you please consider including it in the package or having it created upon installation? If it's not the right thing to do in all cases, could you please add some instructions or hints to README.Debian? 1. https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05035.html 2. https://www.eclipse.org/jetty/documentation/current/deployment-architecture.html#default-web-app-provider Thanks, -J.P. Larocque -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages solr-jetty depends on: ii default-jdk [java5-sdk]2:1.8-58 ii jetty9 9.2.21-1 ii libjetty9-extra-java 9.2.21-1 ii openjdk-8-jdk [java5-sdk] 8u151-b12-1~deb9u1 ii solr-common3.6.2+dfsg-10 solr-jetty recommends no packages. solr-jetty suggests no packages. -- no debconf information -- J.P. Larocque <jpl-debian-...@thoughtcrime.us>
Bug#827203: Found problem with schematic
Hi P.W., I happened to find your bug report. Because it was a little bit alarming, I wanted to see if I could reproduce it. I could reproduce what you saw (the merged nets), but I found that the cause was a wire which was graphically hidden by the edge of the hierarchical sheet. There is a wire segment on the root sheet (bug_hlabels.sch) directly between the hierarchical sheet pins cd1 (6.150, 2.300) and cd2 (6.150, 2.450). If you move the sheet out of the way, you can see the wire. I've attached screenshots to help illustrate. I guess this might leave something to be desired in the UI, but it was possible to track down the cause by moving things and deleting them. Hope this helps, -- J.P. Larocque <jpl-debian-...@thoughtcrime.us>
Bug#856180: Reproduced in testing
Control: found -1 kicad/4.0.5+dfsg1-4 I read that I shouldn't be reporting bugs in packages from backports (sorry about that), so I installed a fresh copy of Stretch, installed kicad in that VM, and reproduced the issue in the above version of the package. -- J.P. Larocque <jpl-debian-...@thoughtcrime.us>
Bug#856180: eeschema: Failed assertion when editing component with aliases
amp;, wchar_t**) [59] __libc_start_main -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (700, 'stable-updates'), (700, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kicad depends on: ii kicad-common4.0.5+dfsg1-4~bpo8+1 ii libboost-context1.55.0 1.55.0+dfsg-3 ii libboost-date-time1.55.01.55.0+dfsg-3 ii libboost-filesystem1.55.0 1.55.0+dfsg-3 ii libboost-iostreams1.55.01.55.0+dfsg-3 ii libboost-locale1.55.0 1.55.0+dfsg-3 ii libboost-program-options1.55.0 1.55.0+dfsg-3 ii libboost-regex1.55.01.55.0+dfsg-3 ii libboost-system1.55.0 1.55.0+dfsg-3 ii libboost-thread1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18+deb8u7 ii libcairo2 1.14.0-2.1+deb8u2 ii libcurl3-gnutls 7.38.0-4+deb8u5 ii libgcc1 1:4.9.2-10 ii libgl1-mesa-glx [libgl1]13.0.4-1~bpo8+1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1] 9.0.0-2 ii libgomp14.9.2-10 ii libice6 2:1.0.9-1+b1 ii libpython2.72.7.9-2+deb8u1 ii libsm6 2:1.2.2-1+b1 ii libstdc++6 4.9.2-10 ii libwxbase3.0-0 3.0.2-1+b1 ii libwxgtk3.0-0 3.0.2-1+b1 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 ii python 2.7.9-1 ii python-wxgtk3.0 3.0.1.1+dfsg-2 pn python:any Versions of packages kicad recommends: ii xsltproc 1.1.28-2+deb8u2 Versions of packages kicad suggests: ii extra-xdg-menus 1.0-4 ii kicad-doc-en 4.0.5+dfsg1-4~bpo8+1 -- no debconf information -- J.P. Larocque <j...@thoughtcrime.us>
Bug#834219: hamster-applet: Launches handler for directory (e.g. Decibel Audio Player) upon saving non-HTML report
Package: hamster-applet
Version: 2.91.3+git20120514.b9fec3e1-1
Severity: normal
Hi,
While trying out Hamster, I saved a report in TSV format, and then
Decibel Audio Player launched and automatically started playing music
in a couple subdirectories down from the directory to which I saved
the TSV report. That is, I saved to /tmp/report, and Decibel fired up
playing music in /tmp/foo/bar/*.flac.
My best educated guess as to why this is happening is that Hamster
"launches" (in some sense) the directory to which the report is saved
(/tmp in my case), due to closure named on_report_chosen() in the
method on_export_active() in the class hamster.overview.Overview,
defined in /usr/share/pyshared/hamster/overview.py . Line 228 of this
file (in the version being reported against) seems to be the offender:
220 def on_report_chosen(widget, format, path):
221 self.report_chooser = None
222 reports.simple(self.facts, self.start_date, self.end_date,
format, path)
223
224 if format == ("html"):
225 webbrowser.open_new("file://%s" % path)
226 else:
227 try:
228 gtk.show_uri(gtk.gdk.Screen(), "file://%s" %
os.path.split(path)[0], 0L)
229 except:
230 pass # bug 626656 - no use in capturing this one i
think
I notice that /usr/share/applications/mimeinfo.cache on my system
contains this entry:
inode/directory=decibel-audio-player.desktop;
And I notice that Decibel does a recursive search and starts
automatically playing when you start it with a directory name on the
command line.
What is the intention the call to gtk.show_uri() on line 228? Is
Hamster doing the right thing? Is Decibel in the wrong here? I don't
know exactly what's supposed to happen, but I figure it's probably not
this.
(Decibel fixed this; see #611938, but this looks like a more general
problem with Hamster. Also, I had no luck finding any relevant "bug
626656" on the web, which I thought might shed some light on the
intended action.)
Thanks for looking into this!
-J.P. Larocque
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (700, 'stable-updates'), (700, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages hamster-applet depends on:
ii gconf23.2.6-3
ii python2.7.9-1
ii python-cairo 1.8.8-1+b2
ii python-dbus 1.2.0-2+b3
ii python-gconf 2.28.1+dfsg-1.1
ii python-gnome2 2.28.1+dfsg-1.1
ii python-gobject-2 2.28.6-12+b1
ii python-gtk2 2.24.0-4
ii python-wnck 2.32.0+dfsg-3
ii python-xdg0.25-4
ii python2.6 2.6.8-1.1
ii python2.7 2.7.9-2
Versions of packages hamster-applet recommends:
ii gnome-icon-theme 3.12.0-1
ii python-notify 0.1.1-4
Versions of packages hamster-applet suggests:
pn python-evolution
-- no debconf information
--
J.P. Larocque <jpl-debian-...@thoughtcrime.us>
Bug#644348: python-pycountry: Ships README in odd directory rather than /usr/share/doc/
Package: python-pycountry Version: 0.12.1+ds1-1 Severity: normal Hi, python-pycountry ships a README in /usr/share/pyshared/pycountry/README.txt , but there is no actual documentation in /usr/share/doc/python-pycountry . Shouldn't the README be placed in that directory instead? Thanks, -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pycountry depends on: ii iso-codes 3.23-1 ISO language, territory, currency, ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-support 1.0.10 automated rebuilding support for P python-pycountry recommends no packages. python-pycountry suggests no packages. -- no debconf information -- J.P. Larocque j...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524341: Further info on Polipo Accept-Encoding problem
-alive -- J.P. Larocque jpl-debian-...@thoughtcrime.us msie.pcap Description: application/cap
Bug#619539: Correction
Wherever I wrote pgsql, I meant psql. Sorry! -- J.P. Larocque jpl-debian-...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619539: postgresql-client-8.4: Crashes when editing input line longer than screen
Package: postgresql-client-8.4 Version: 8.4.7-0squeeze2 Severity: normal Hi, pgsql crashes in interactive mode when you execute a multiline query which takes up more than the height of the screen, then press the up-arrow key to edit that query. I can reliably reproduce this problem on two amd64 machines (assuming bash as the shell for $LINES): 1. Run this to generate a long query. python -c 'import sys; count, = map (int, sys.argv[1:]); print SELECT + ,\n.join (map (str, range (1, count + 1))) + ;' $(expr $LINES + 1) 2. Run pgsql. 3. Copy and paste the long, generated query into pgsql. This query should be longer in lines than the height of your screen, so the initial SELECT 1, should not be visible. 4. Exit your pager (if your pager came up to show the long query result). 5. Press up-arrow. 6. Voila! Segmentation fault. Hope this helps, -- System Information: Debian Release: 6.0.1 APT prefers squeeze-updates APT policy: (750, 'squeeze-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postgresql-client-8.4 depends on: ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libedit22.11-20080614-2 BSD editline and history libraries ii libpq5 8.4.7-0squeeze2 PostgreSQL C client library ii libssl0.9.8 0.9.8o-4squeeze1 SSL shared libraries ii postgresql-client-commo 113 manager for multiple PostgreSQL cl ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime postgresql-client-8.4 recommends no packages. Versions of packages postgresql-client-8.4 suggests: pn postgresql-8.4none (no description available) pn postgresql-doc-8.4none (no description available) -- no debconf information -- J.P. Larocque jpl-debian-...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555456: Update to e2fsck bonehead problem: reproducible case found
Hi Ted and Micah, I ran into the problem in e2fsck that prints: WARNING: PROGRAMMING BUG IN E2FSCK! OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM. inode_link_info[X] is Y, inode.i_links_count is Z. They should be the same! I've sent a full transcript, e2image file with which the problem can be reproduced, and background information to 555...@bugs.debian.org, which you can access at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555456. (I'm sending this message separately to spare you both from the 2.1MiB attachment.) Hope it helps. Thanks! -- J.P. Larocque jpl-debian-...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551133: sbcl: TIME sometimes endlessly spews zeroes (#551133)
Hi, I would have responded sooner, but it looks like the last character of my e-mail address was truncated in your message. On Tue, Nov 03, 2009 at 05:52:14PM +0100, Peter Van Eynde wrote: I'm trying but cannot reproduce this anymore with 1:1.0.31.0-2: Am I testing correctly? Yes. I upgraded to 1:1.0.25.0-1, which fixes the bug. (I couldn't find the bug in src/code/time.lisp because I had foolishly downloaded the source to that new version, not the one which I experienced the bug with.) Thanks, -- J.P. Larocque j...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551133: sbcl: TIME sometimes endlessly spews zeroes
Package: sbcl Version: 1:1.0.18.0-2 Severity: normal Sometimes (TIME x) prints #\0 endlessly. It looks like the condition is when the evaluation of x takes a whole number of wall-clock seconds greater than 1 (+/- 1ms). Examples (Ctrl+C successfully interrupts SBCL): sbcl --noinform --eval '(time (sleep 2))' --eval '(sb-ext:quit)' sbcl --noinform --eval '(time (sleep 9))' --eval '(sb-ext:quit)' If you don't see the problem, it's probably because SLEEP took e.g. 2.001 seconds instead of 2.000. Keep trying. Other cases of (TIME (SLEEP n)), where n is 0, 1 or not an integer, don't suffer from the same problem. It looks like the implementation of TIME uses FORMAT-MILLISECONDS, which suffers from the same problem. I tried finding the bug in %FORMAT-DECIMAL (called by FORMAT-MILLISECONDS), but it looks like the loop it's getting caught in (the one in the %ZEROES local function) should terminate in all cases, so I couldn't pinpoint the error. (SB-IMPL::FORMAT-MILLISECONDS *standard-output* 2001 nil nil) 2.001 seconds = seconds (SB-IMPL::FORMAT-MILLISECONDS *standard-output* 2000 nil nil) 2.0... = (doesn't return) Thanks for taking a look at this, -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (700, 'stable'), (650, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sbcl depends on: ii common-lisp-controller6.17 Common Lisp source and compiler ma ii libc6 2.9-25 GNU C Library: Shared libraries Versions of packages sbcl recommends: pn binfmt-supportnone (no description available) Versions of packages sbcl suggests: pn sbcl-doc none(no description available) pn sbcl-sourcenone(no description available) ii slime 1:20080223.dfsg-1 Superior LISP Interaction Mode for -- no debconf information -- J.P. Larocque j...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550814: mp3splt: Is not lossless
audio decoder library ii libogg0 1.1.3-4Ogg Bitstream Library ii libvorbis0a 1.2.0.dfsg-3.1 The Vorbis General Audio Compressi ii libvorbisfile31.2.0.dfsg-3.1 The Vorbis General Audio Compressi mp3splt recommends no packages. mp3splt suggests no packages. -- no debconf information -- J.P. Larocque j...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546267: pngcrush: Corrupts image with -bit_depth 8
On Sun, Sep 20, 2009 at 10:41:17AM +0530, Kapil Hari Paranjape wrote: The program currently does not do colour counting which is necessary to convert from greater depth to lower depth. Thus what is happening is that the image is being truncated and stretched horizontally along with a graying of the colours. I would then argue that pngcrush should fail gracefully when any combination of arguments given to it would corrupt the image due to internal implementation details (that is, whether color counting is implemented yet). By analogy, a program shouldn't segfault if you pass it a command-line argument it doesn't support. Thanks, -- J.P. Larocque j...@thoughtcrime.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539573: xmlstarlet: Should return non-zero on error
Package: xmlstarlet Version: 1.0.1-2 Severity: normal xmlstarlet should return a non-zero exit code when an error occurs, as in Unix convention. Example of current behavior: $ xmlstarlet sel -t -c / /nonexistent; echo $? warning: failed to load external entity /nonexistent 0 This makes it hard to write reliable scripts/programs that do something meaningful on error. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xmlstarlet depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libxml22.6.32.dfsg-5 GNOME XML library ii libxslt1.1 1.1.24-2 XSLT processing library - runtime ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime xmlstarlet recommends no packages. xmlstarlet suggests no packages. -- no debconf information -- J.P. Larocque: j...@thoughtcrime.us, +1 509 324-2410 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516469: guile-1.6: libguile could potentially free static memory
Package: guile-1.6
Version: 1.6.8-6.3
Severity: minor
Tags: patch
Hi,
While trying to track down a bug in a client application which links
to guile-1.6, I made a debugging modification to scm_take_str().
scm_take_str() takes a string in some given dynamically-allocated
buffer and returns a Guile string object for it. The GC takes
responsibility for freeing that original buffer, at some point in the
future. Within the application I am debugging, I believe that
scm_take_str() was being given static memory somewhere down the line,
because glibc and valgrind would report invalid frees, and I traced
some of that memory to this function. To get closer to the source of
the error in the application, my modification immediately frees the
given dynamic buffer, after allocating a new one and copying the
contents of the original buffer to the new buffer; the new buffer is
then used for the returned string object.
Because the buffer passed to scm_take_str is fair game for free() (as
noted in the comment preceding it), I think this is a valid
modification:
This function must only be applied to memory obtained via malloc,
since the GC is going to apply `free' to it when the string is
dropped.
However, I wasn't able to build a package from this modified copy of
guile-1.6. The failure occurs when the built interpreter is used to
build the documentation. I tracked the problem down to
libguile/options.c:225(scm_init_opts):
void
scm_init_opts (SCM (*func) (SCM), scm_t_option options[], int n)
{
[...snipped...]
doc = scm_take0str (options[i].doc);
scm_take0str() is implemented with scm_take_str(), and therefore its
input memory must also be dynamically-allocated and free()able. This
means that the doc members of the scm_t_option structures given to
scm_init_opts() must be dynamically-allocated. However, in all the
callers to scm_init_opts(), the argument for options is a static
array of static structures with static strings. For example, this is
scm_print_opts (from libguile/print.c), which scm_init_print() passes
to scm_init_opts():
scm_t_option scm_print_opts[] = {
{ SCM_OPTION_SCM, closure-hook, SCM_UNPACK (SCM_BOOL_F),
Hook for printing closures (should handle macros as well). },
{ SCM_OPTION_BOOLEAN, source, 0,
Print closures with source. }
};
Since all cases of options[i].doc in the above line from
scm_init_opts() seem to be static, not dynamic, I replaced
scm_take0str with scm_makfrom0str. scm_makfrom0str() does the
right thing in this case, by dynamically-allocating a new string and
copying the given string to it. This change let me build guile-1.6
with my scm_take_str() hack:
--- orig/guile-1.6-1.6.8/libguile/options.c 2005-06-09 15:42:55.0
-0700
+++ guile-1.6-1.6.8/libguile/options.c 2009-02-21 07:32:58.0 -0800
@@ -222,7 +222,7 @@
name = scm_str2symbol (options[i].name);
options[i].name =(char *) name;
scm_permanent_object (name);
- doc = scm_take0str (options[i].doc);
+ doc = scm_makfrom0str (options[i].doc);
options[i].doc = (char *) doc;
scm_permanent_object (doc);
if (options[i].type == SCM_OPTION_SCM)
I should emphasize that I believe this change is required for
guile-1.6 to be internally consistent with its own preconditions for
scm_take_str(), even if the flaw never manifests itself in a
user-visible bug. (Maybe the SCM strings being created are always
reachable, and therefore never freed. My hack identified the problem
immediately because it unconditionally frees all memory passed to
scm_take_str, not just when the resulting Guile string object is found
to be unreachable by the GC.)
Because this is fairly pedantic and may not actually affect anyone, I
chose the minor severity level. :)
--
J.P. Larocque: j...@thoughtcrime.us, +1 509 324-2410
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516328: xbindkeys GC problem solved
tags 516328 + patch thanks Hi, It turns out the problem has nothing to do with the pipe or fork procedures. It occurs whenever enough consing happens to trigger a GC (but not from the toplevel of the .xbindkeysrc.scm file--see below). A third test case is attached which demonstrates this, test-3.scm. The Guile GC was trying to free a string object that was backed by static memory. The string in question named the xbindkeys initialization file. The Guile string object was constructed with the scm_take0str C function in options.c:857(get_rc_guile_file). This function expects dynamically-allocated memory, and it takes responsibility to free it with a future GC. However, the string given to scm_take0str (rc_guile_file) is statically-allocated (xbindkeys.c:55). The fix is simple: use scm_makfrom0str, which copies its given C string to newly-allocated memory which is then associated with the Guile string it returns, making the returned string safe to GC. All three test cases pass, on i386 and amd64, with this fix: --- orig/xbindkeys-1.8.2/options.c 2007-04-18 14:47:03.0 -0700 +++ xbindkeys-1.8.2/options.c 2009-02-21 08:38:25.0 -0800 @@ -854,7 +854,7 @@ fclose (stream); init_xbk_guile_fns(); - scm_primitive_load(scm_take0str(rc_guile_file)); + scm_primitive_load(scm_makfrom0str(rc_guile_file)); return 0; } I'm guessing that the reason the problem doesn't occur on the toplevel is because scm_primitive_load is still on the stack, holding a reference to the Guile source file name string it was given. The only thing magical about the xbindkey-function procedure is that the procedure that is passed to it is eventually called asynchronously, after scm_primitive_load has finished, and the Guile string naming the source file is unreachable. I guess nobody else does anything interesting enough with their Scheme code in .xbindkeysrc.scm to trigger a GC. :) -- J.P. Larocque: j...@thoughtcrime.us, +1 509 324-2410 (define (cons-a-bit) (define (zero-to-99) (let loop ((i 0) (acc '())) (if (= i 100) (reverse acc) (loop (+ 1 i) (cons* i acc) (display (number-string (car (last-pair (zero-to-99) (newline)) (define (cons-loop) (let loop () (cons-a-bit) (loop))) (xbindkey-function '(F10) cons-loop) ;;; The problem cannot be reproduced directly here, on the toplevel of ;;; the rc file: (uncomment and try xbindkeys with -n from a terminal) ;(cons-loop)
Bug#516328: xbindkeys: GC-related crash triggered by Scheme pipe and fork procedures
Package: xbindkeys Version: 1.8.2-1 Severity: normal Hi, I've found crashes that are triggered by two different Scheme programs that call (pipe) and (fork), respectively. Both crashes list GC-related functions in their glibc-generated backtraces, and are ultimately terminated by glibc for bad calls to free. I couldn't reproduce these problems with guile-1.6 directly, or with xbindkeys at the top-level of the configuration file. I could only reproduce them from within the dynamic extent of the xbindkey-function procedure. I've attached the two test-cases: test-1.scm and test-2.scm. To reproduce, run xbindkeys -n -fg FILENAME and press F10 (the key I've bound for both tests). Of course, these test cases were distilled down from an actual configuration of xbindkeys I was trying to create; these are not pointless exercises. I've also attached the output of running the tests on an i386 machine (test-1-result-i386.txt, test-2-result-i386.txt) and the results on an amd64 machine (test-1-result-amd64.txt, test-2-result-amd64.txt). On the amd64 machine, xbindkeys crashes immediately after the key-presses, before any loop iterations complete. Please let me know if I could do anything else to help fix these problems. Thanks, -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-12-custom-xen-ws-1 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xbindkeys depends on: ii guile-1.6-libs1.6.8-6.3 Main Guile libraries ii libc6 2.7-18 GNU C Library: Shared libraries ii libguile-ltdl-1 1.6.8-6.3 Guile's patched version of libtool ii libx11-6 2:1.1.5-2 X11 client-side library xbindkeys recommends no packages. Versions of packages xbindkeys suggests: ii tk8.4 [wish] 8.4.19-2 Tk toolkit for Tcl and X11, v8.4 - ii tk8.5 [wish] 8.5.3-4Tk toolkit for Tcl and X11, v8.5 - ii xbindkeys-config 0.1.3-1+b1 An easy to use gtk program for con -- no debconf information -- J.P. Larocque: j...@thoughtcrime.us, +1 509 324-2410 (define (make-pipe) (display making pipe) (newline) (let ((pipe-ports (pipe))) (display closing) (newline) (close-port (car pipe-ports)) (close-port (cdr pipe-ports (define (pipe-loop) (let loop () (make-pipe) (loop))) (xbindkey-function '(F10) pipe-loop) ;;; The problem cannot be reproduced without xbindkey-function: ;;; (uncomment and try xbindkeys with -n from a terminal) ;(pipe-loop) (define (fork-and-print) (let ((child-pid (primitive-fork))) (cond ((zero? child-pid) ; We're the child. (display forked) (newline) (force-output) (primitive-exit 0)) (else child-pid (define (stress-test) (let loop () ;; Note that xbindkey-function seems to automatically call ;; waitpid, which is a separate bug. We don't call waitpid ;; ourselves in order to avoid triggering that bug, which would ;; mask this separate bug--the crash. (fork-and-print) (loop))) (xbindkey-function '(F10) stress-test) Script started on Fri Feb 20 07:52:06 2009 making pipe closing [8 cycles omitted] making pipe *** glibc detected *** xbindkeys: free(): invalid pointer: 0x080512a0 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7c21624] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7c23826] /usr/lib/libguile.so.12(scm_must_free+0x21)[0xb7dc1ce1] /usr/lib/libguile.so.12(scm_gc_sweep+0x488)[0xb7dc23b8] /usr/lib/libguile.so.12(scm_igc+0x279)[0xb7dc26f9] /usr/lib/libguile.so.12[0xb7dc2808] /usr/lib/libguile.so.12(scm_must_malloc+0x37)[0xb7dc2957] /usr/lib/libguile.so.12[0xb7dbfc80] /usr/lib/libguile.so.12(scm_fdes_to_port+0x124)[0xb7dbfde4] /usr/lib/libguile.so.12(scm_pipe+0x41)[0xb7e13691] /usr/lib/libguile.so.12(scm_ceval+0x1543)[0xb7db6263] /usr/lib/libguile.so.12(scm_ceval+0x5e9)[0xb7db5309] /usr/lib/libguile.so.12(scm_ceval+0x887)[0xb7db55a7] /usr/lib/libguile.so.12(scm_apply+0x6ff)[0xb7db850f] /usr/lib/libguile.so.12(scm_call_0+0x2d)[0xb7dbd9bd] xbindkeys[0x8049de7] /usr/lib/libguile.so.12(scm_boot_guile+0x62)[0xb7dd1282] xbindkeys[0x8049545] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7bc9455] xbindkeys[0x8049461] === Memory map: 08048000-08051000 r-xp fe:01 213874 /usr/bin/xbindkeys 08051000-08052000 rw-p 9000 fe:01 213874 /usr/bin/xbindkeys 0920b000-0927d000 rw-p 0920b000 00:00 0 [heap] b7a0-b7a21000 rw-p b7a0 00:00 0 b7a21000-b7b0 ---p b7a21000 00:00 0 b7b2f000-b7b3b000 r-xp fe:01 16448 /lib/libgcc_s.so.1 b7b3b000-b7b3c000 rw-p b000 fe:01 16448 /lib/libgcc_s.so.1 b7b3c000-b7b8c000 rw-p b7b3c000 00:00 0 b7b8c000-b7b9 r-xp fe:01 200717 /usr/lib/libXdmcp.so.6.0.0 b7b9-b7b91000 rw-p
Bug#492004: cl-net-telent-date: Doesn't export *HTTP-DATE-TIME-PATTERNS*
Package: cl-net-telent-date Version: 1:0.4.1-4 Severity: wishlist The (Common Lisp) package NET.TELENT.DATE doesn't export the symbol *HTTP-DATE-TIME-PATTERNS*. It should, because: 1) If I were to use this library to parse HTTP times, the right way (or strict way) would be something like: (net.telent.date:parse-time http-date :patterns net.telent.date:*http-date-time-patterns*) 2) The symbol isn't used for anything internally, so it was probably intended to be used externally. Thanks, -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cl-net-telent-date depends on: ii common-lisp-controller6.15 Common Lisp source and compiler ma cl-net-telent-date recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490767: libsaxonb-java: Broken symlink: /usr/share/java/saxonb-dom4j.jar
Package: libsaxonb-java Version: 9.0.0.4+svn20080322-1 Severity: normal This package ships with a symlink /usr/share/java/saxonb-dom4j.jar. The referent is saxonb-dom4j9.0.jar, which doesn't exist. This was probably just a typo, as saxonb-dom4j-9.0.jar does exist. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libsaxonb-java depends on: ii libdom4j-java 1.6.1+dfsg-3 flexible XML framework for Java ii libjdom1-java 1.0-4lightweight and fast library using ii libxom-java 1.1-3A new XML object model for Java ii sun-java6-jre [java2-runtim 6-06-1 Sun Java(TM) Runtime Environment ( libsaxonb-java recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390793: Applies to genisoimage
severity 390793 minor reassign 390793 genisoimage 1.1.2-1 thanks I think that this bug is too important for wishlist severity: as many (nearly all) systems rely on file name extensions to know the type of a file, this breaks things. For example, appliances which play data CDs with MP3s: long names get their .mp3 extension truncated, and therefore the player skips them and offers no means to play them. Also, I reassigned the bug to genisoimage because, near as I can tell, mkisofs is old news, and this will help get the bug seen. It certainly applies to genisoimage. Sorry if this is incorrect or stepping on anyone's toes. Here's how to reproduce the problem: $ mkdir sample_root $ touch sample_root/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.foo $ genisoimage -J -o sample.iso sample_root Warning: creating filesystem with Joliet extensions but without Rock Ridge extensions. It is highly recommended to add Rock Ridge. I: -input-charset not specified, using utf-8 (detected in locale settings) Total translation table size: 0 Total rockridge attributes bytes: 0 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 180 extents written (0 MB) $ sudo mount -o ro,loop,norock sample.iso /mnt ls /mnt sudo umount /mnt abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl $ sudo mount -o ro,loop,norock,nojoliet sample.iso /mnt ls /mnt sudo umount /mnt abcdefgh.foo -- J.P. Larocque: [EMAIL PROTECTED], +1 509-324-2410 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433596: clisp: Stack overflow taking rational values of extreme long-floats
Package: clisp Version: 1:2.41-1 Severity: normal Hi, I can't take the rational value of any of the six extreme long-float constants listed below: for var in least-positive-long-float \ least-negative-long-float \ least-positive-normalized-long-float \ least-negative-normalized-long-float \ most-positive-long-float \ most-negative-long-float; do clisp -ansi -q -x '(let ((var ''$var')) (format t ~~S = var) (write (rational (symbol-value var' done LEAST-POSITIVE-LONG-FLOAT = *** - Program stack overflow. RESET LEAST-NEGATIVE-LONG-FLOAT = *** - Program stack overflow. RESET LEAST-POSITIVE-NORMALIZED-LONG-FLOAT = *** - Program stack overflow. RESET LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT = *** - Program stack overflow. RESET MOST-POSITIVE-LONG-FLOAT = *** - Program stack overflow. RESET MOST-NEGATIVE-LONG-FLOAT = *** - Program stack overflow. RESET Similarly when invoked with -m 32M or -m 128M. I'm pretty sure this shouldn't happen. Thanks, -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-12-custom-xen-ws-1 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages clisp depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libncurses5 5.5-5Shared libraries for terminal hand ii libreadline55.2-2GNU readline and history libraries ii libsm6 1:1.0.1-3X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxpm4 1:3.5.5-2X11 pixmap library clisp recommends no packages. -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433592: clisp: Float/rational comparison sometimes underflows; should never
Package: clisp Version: 1:2.41-1 Severity: normal Hi, I'm trying to compare a floating-point number and a rational. According to the rule of float and rational contagion, described in CLHS 12.1.4.1, and X3J13 issue CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE, such a comparison should always return the mathematically correct result, as if the floating-point number were first converted to a rational with RATIONAL. Instead, CLISP signals an underflow condition: $ clisp -q -x '( (expt 10 -100) least-positive-short-float)' *** - floating point underflow The Implementation Notes for GNU CLISP, sections 12.2.3.1 and 12.2.3.2, don't seem to say anything about comparisons, but mention two variables which control ANSI-compliance. CLISP behaves the same when invoked with -ansi, to set these and any similar variables to T. $ clisp -ansi -q -x '( (expt 10 -100) least-positive-short-float)' *** - floating point underflow This X3J13 issue is listed as supported in the Implementation Notes for GNU CLISP: http://clisp.cons.org/impnotes.html#issues CLISP behaves as expected if the floating-point number is filtered through RATIONAL. (Note that CLHS 12.1.4.1 explicitly states When rationals and floats are compared by a numerical function, the function rational is effectively called to convert the float to a rational and then an exact comparison is performed.) $ clisp -q -x '( (expt 10 -100) (rational least-positive-short-float))' T $ clisp -q -x '( (expt 10 -10) (rational least-positive-short-float))' NIL I'm fairly certain CLISP is in error. Thanks, -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-12-custom-xen-ws-1 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages clisp depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libncurses5 5.5-5Shared libraries for terminal hand ii libreadline55.2-2GNU readline and history libraries ii libsm6 1:1.0.1-3X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxpm4 1:3.5.5-2X11 pixmap library clisp recommends no packages. -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414307: xnest: Crashes with client Tulip
Package: xnest Version: 2:1.1.1-20 Severity: important Xnest consistently crashes with the application Tulip (Debian package tulip, version 2.0.6-4). Simply create a new document. Tulip on AMD64 also crashes xserver-xorg-core 2:1.1.1-19 on i386 during the same operation. Tulip on i386 also crashes the same version of xserver-xorg-core on i386. This could be considered a much more serious problem when it crashes a real X server; thankfully it can be reproduced with Xnest. A backtrace from the core file left by the Xnest follows. Please let me know if there's any particular detailed information I can give that will help. Core was generated by `Xnest -geometry 838x1029 -query synthetic-forms'. Program terminated with signal 11, Segmentation fault. #0 0x004fde07 in _mesa_shareContext () (gdb) bt #0 0x004fde07 in _mesa_shareContext () #1 0x004bc0f4 in GlxInitVisuals () #2 0x004bb366 in GlxInitVisuals () #3 0x0048e26a in GlxInitVisuals () #4 0x0048a524 in XETrapDispatch () #5 0x004329e9 in dixDestroyPixmap () #6 0x004435fd in NotImplemented () #7 0x2ba424d404ca in __libc_start_main () from /lib/libc.so.6 #8 0x0041d84a in ?? () #9 0x7fff866c6d98 in ?? () #10 0x in ?? () Thanks, -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-custom-xen-1 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xnest depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libx11-62:1.0.3-5X11 client-side library ii libxau6 1:1.0.1-2X11 authorisation library ii libxdmcp6 1:1.0.1-2X11 Display Manager Control Protoc ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxfont1 1:1.2.2-1X11 font rasterisation library xnest recommends no packages. -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408840: Won't honor CDR_FIFOSIZE in /etc/wodim.conf
Package: wodim Version: 9:1.1.1-1 Severity: normal wodim seems to ignore the CDR_FIFOSIZE setting in /etc/wodim.conf . Light debugging of defaults.c shows that it's seeing the -1 in my cdrom= device line and missing the CDR_FIFOSIZE setting, eventually reverting to the default of 4MB. If I specify a FIFO size in the device line, wodim honors it. I'm invoking it with wodim -dummy -v some WAV files. My /etc/wodim.conf follows. ---8---8--- # wodim.dfl Copyright 2006 E. Bloch # Based on cdrecord.dfl (Copyright 1998 J. Schilling) # # This file is /etc/wodim.conf # It contains defaults that are used if no command line option # or environment is present. # # The default device, if not specified elsewhere. # #CDR_DEVICE=yamaha CDR_DEVICE=cdrom # # The default speed, if not specified elswhere. # # For MMC compliant drives, the default is to write at maximum speed, so it in # general does not make sense to set up a default speed in /etc/wodim.conf. # #CDR_SPEED=40 # # The default FIFO size if, not specified elswhere. # #CDR_FIFOSIZE=16m CDR_FIFOSIZE=32m # # CDR_MAXFIFOSIZE can limit the maximum allowed FIFO size. This is useful to # not let mallicious users allocate too much system memory if no ulimit is set # or wodim runs with suid-root permissions. # # CDR_MAXFIFOSIZE=256m # # The following definitions allow abstract device names. They are used if the # device name does not contain the the characters ',', ':', '/' and '@' # # Unless you have a good reason, use speed == -1 and let wodim use its internal # drive specific defaults. # # drive namedevice speed fifosize driveropts # #default= USCSI:1,0,0 -1 -1 burnfree #sanyo= 1,4,0 -1 -1 burnfree #cdrom= 0,6,0 2 1m #remote=REMOTE:[EMAIL PROTECTED]:1,0,0 16 16m burnfree # cdrom= /dev/cdrw -1 -1 burnfree ---8---8--- -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages wodim depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. Versions of packages wodim recommends: ii genisoimage 9:1.1.1-1 Creates ISO-9660 CD-ROM filesystem -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408844: Man page error: grace time before burn is 4 seconds
Package: wodim Version: 9:1.1.1-1 Severity: minor From the Diagnostics section of wodim(1): You have 9 seconds to abort wodim start after you see the message: Starting to write CD at speed %d in %s mode for %s session. In most shells you can do that by pressing Ctrl-C. In fact, the default grace time must have changed some time ago (?), as on my system the time is more like 4 seconds. The message text is also slightly different (pedantry): Starting to write CD/DVD at speed 8.0 in real SAO mode for single session. Last chance to quit, starting real write3 seconds. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages wodim depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. Versions of packages wodim recommends: ii genisoimage 9:1.1.1-1 Creates ISO-9660 CD-ROM filesystem -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408298: e2fsprogs: resize2fs doesn't honor s sector unit designator in size parameter
Package: e2fsprogs Version: 1.39+1.40-WIP-2006.11.14+dfsg-1 Severity: normal resize2fs isn't honoring the s unit designator. Per resize2fs(8): The size parameter specifies the requested new size of the filesystem. If no units are specified, the units of the size parameter shall be the filesystem blocksize of the filesystem. Optionally, the size parameter may be suffixed by one of the following the units designators: 's', 'K', 'M', or 'G', for 512 byte sectors, kilobytes, megabytes, or gigabytes, respectively. In the test case documented below, it's treating the quantity as units of 2048 bytes, not as units of 512 bytes. $ touch test.ext2 /sbin/mke2fs -F -b 4096 test.ext2 4096 mke2fs 1.40-WIP (14-Nov-2006) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 4096 inodes, 4096 blocks 204 blocks (4.98%) reserved for the super user First data block=0 1 block group 32768 blocks per group, 32768 fragments per group 4096 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 30 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. $ /sbin/resize2fs test.ext2 65536s resize2fs 1.40-WIP (14-Nov-2006) Resizing the filesystem on test.ext2 to 32768 (4k) blocks. The filesystem on test.ext2 is now 32768 blocks long. $ ls -l test.ext2 -rw-r--r-- 1 piranha piranha 134217728 2007-01-24 08:37 test.ext2 $ nickle -e '134217728 / 512' # Calculate resulting sector count. 262144 -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages e2fsprogs depends on: ii e2fslibs 1.39+1.40-WIP-2006.11.14+dfsg-1 ext2 filesystem libraries ii libblkid 1.39+1.40-WIP-2006.11.14+dfsg-1 block device id library ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libcomer 1.39+1.40-WIP-2006.11.14+dfsg-1 common error description library ii libss2 1.39+1.40-WIP-2006.11.14+dfsg-1 command-line interface parsing lib ii libuuid1 1.39+1.40-WIP-2006.11.14+dfsg-1 universally unique id library e2fsprogs recommends no packages. -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406963: nbd-server: postinst script breaks custom server options
Package: nbd-server
Version: 1:2.8.7-3
Severity: normal
Tags: patch
I have the following /etc/nbd-server file:
NBD_PORT[0]=21544
NBD_FILE[0]=/var/lib/nbd/pulk-pull/swap
NBD_SERVER_OPTS[0]=-l /var/lib/nbd/pulk-pull/swap.nbd-allow
NBD_PORT[1]=37417
NBD_FILE[1]=/var/lib/nbd/oomingmak/swap
NBD_SERVER_OPTS[1]=-l /var/lib/nbd/oomingmak/swap.nbd-allow
[comments omitted]
The following occurs when I run dpkg-reconfigure nbd-server, or
reinstall nbd-server:
/var/lib/dpkg/info/nbd-server.postinst: line 52: [: -l: binary operator expected
/var/lib/dpkg/info/nbd-server.postinst: line 52: [: -l: binary operator expected
/etc/nbd-server: line 3: /var/lib/nbd/pulk-pull/swap.nbd-allow: Permission
denied
/etc/nbd-server: line 6: /var/lib/nbd/oomingmak/swap.nbd-allow: Permission
denied
Starting Network Block Device server: /var/lib/nbd/pulk-pull/swap
/var/lib/nbd/oomingmak/swap nbd-server.
/etc/nbd-server then becomes:
NBD_PORT[0]=21544
NBD_FILE[0]=/var/lib/nbd/pulk-pull/swap
NBD_SERVER_OPTS[0]=-l /var/lib/nbd/pulk-pull/swap.nbd-allow
NBD_PORT[1]=37417
NBD_FILE[1]=/var/lib/nbd/oomingmak/swap
NBD_SERVER_OPTS[1]=-l /var/lib/nbd/oomingmak/swap.nbd-allow
[comments omitted]
Note that the NBD_SERVER_OPTS* lines lose proper quoting. The
Permission denied errors on startup happen because bash is trying to
execute the swap.nbd-allow files as a result of the improper
serialization.
This modification to /var/lib/dpkg/info/nbd-server.postinst properly
serializes these values, and also corrects the error reported on line
52:
---8---8---
--- nbd-server.postinst.orig2006-12-31 06:20:08.0 -0800
+++ /var/lib/dpkg/info/nbd-server.postinst 2007-01-15 02:07:52.0
-0800
@@ -9,6 +9,21 @@
[ -e /etc/nbd-server ] . /etc/nbd-server
+# Quotes each argument for shell expression inclusion, to prevent
+# interpretation of special characters.
+function shell_quote () {
+ local first=true
+ while [ $# -gt 0 ]; do
+ if [ ! $first ]; then
+ echo -n ' '
+ fi
+ # sed expression transforms instances of ' to '\''
+ echo -n '$(echo $1 | sed -e s/'/'''/g)'
+ first=
+ shift
+ done
+}
+
# summary of how this script can be called:
#* postinst `configure' most-recently-configured-version
#* old-postinst `abort-upgrade' new version
@@ -49,12 +64,12 @@
umask 066
( echo NBD_PORT[$(( $i + 0 ))]=$PORT
echo NBD_FILE[$(( $i + 0 ))]=$FN
- if [ -z ${NBD_SERVER_OPTS[$(( $i + 0))]} ]
+ if [ -z ${NBD_SERVER_OPTS[$(( $i + 0))]} ]
then
echo #NBD_SERVER_OPTS[$(( $i + 0))] is unset, but
can contain -r, -m, -c or -a.
echo #See nbd-server(1) for their meanings
else
- echo NBD_SERVER_OPTS[$(( $i +
0))]=${NBD_SERVER_OPTS[$(( $i + 0))]}
+ echo NBD_SERVER_OPTS[$(( $i + 0))]=$(shell_quote
${NBD_SERVER_OPTS[$(( $i + 0))]})
fi
) $TMPFILE
done
---8---8---
Two subsequent iterations of dpkg-reconfigure nbd-server preserve
the semantic meaning of the NBD_SERVER_OPTS* lines (though harmlessly
changing my original double-quoted strings to single-quoted strings),
and report no errors.
I've also commented out NBD_SERVER_OPTS[0] and reconfigured nbd-server
to ensure my patch works correctly when such a value is not set.
On what perhaps should be filed in a separate bug report: Why aren't
the NBD_SERVER_OPTS* lines configurable with debconf?
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.29-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages nbd-server depends on:
ii debconf [debconf-2.0]1.5.11 Debian configuration management sy
ii libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii libglib2.0-0 2.12.4-2The GLib library of C routines
nbd-server recommends no packages.
-- debconf information:
* nbd-server/filename: /var/lib/nbd/pulk-pull/swap
* nbd-server/port: 21544
* nbd-server/filename1: /var/lib/nbd/oomingmak/swap
* nbd-server/port1: 37417
nbd-server/autogen:
* nbd-server/number: 2
--
J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402490: [Polipo-users] Bug#402490: polipo: Incorrectly caches 302 responses, breaking LiveJournal
On Mon, Dec 11, 2006 at 04:35:45PM +0100, Juliusz Chroboczek wrote: Oh my, what a silly bug -- I've confused 301 and 302. I'm attaching a fix -- could you please confirm whether it fixes LiveJournal? It does, with both Debian's 0.9.10-1 and the snapshot I fetched. The 302 responses are still cached to disk and returned in subsequent Polipo instances, like the dontCacheRedirects bug I reported. Your fix does let me use LiveJournal though; thanks. Tom, regarding Debian bug #334851 (another redirection-loop bug report), it may be worth noting that I can log into (the U.S. version of) eBay without the patch. I cleared my eBay cookies prior to trying to reproduce that bug. -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398170: cl-defsystem3: Wrong path listed in README.Debian
Package: cl-defsystem3 Version: 3.6i+2006.03.13-1 Severity: minor The document /usr/share/doc/cl-defsystem3/README.Debian references a file incorrectly: To load Defsystem3 into your Lisp system, give the command (load /usr/share/common-lisp/source/cl-defsystem3/defsystem.lisp) Should be: To load Defsystem3 into your Lisp system, give the command (load /usr/share/common-lisp/source/defsystem/defsystem.lisp) Thanks, -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.29-xen Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) cl-defsystem3 depends on no packages. Versions of packages cl-defsystem3 recommends: ii common-lisp-controller 6.6 This is a Common Lisp source and c ii sbcl [lisp-compiler]1:0.9.18.0-1 A Common Lisp compiler and develop -- no debconf information -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394775: Sparc64 install fails: 'sbcl.sh install-clc' segfaults
On Mon, Nov 06, 2006 at 02:39:13PM +0100, Peter Van Eynde wrote: If you can recompile sbcl you could try to change the parms.lisp file move the LT to some other place. Maybe #xa000 to #xa080? Disclosure: this is well into the realm of deep magic for me. =) I'd love to recompile, but I can't find a host CL to build SBCL with. The stable package build-depends on sbcl, which of course can't work. Stable's clisp segfaults on installation, too. Both the Debian stable[1] and upstream 0.9.18[2] versions of SBCL won't build with gcl -batch. Even the SPARC binary on the SBCL web site fails[3]. Am I missing any ideas on how to get this going? 1. GNUmakefile:72: depend: No such file or directory 2. Error in GET-MACRO-CHARACTER [or a callee]: NIL is not of type READTABLE 3. After startup banner: ---8---8--- fatal error encountered in SBCL pid 9293: maximum interrupt nesting depth (32) exceeded LDB monitor ldb ---8---8--- -- J.P. Larocque: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394775: Sparc64 install fails: 'sbcl.sh install-clc' segfaults
=S_IFREG|0644, st_size=1017, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f94000
read(3, TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0..., 8192) =
1017
close(3)= 0
munmap(0xf7f94000, 8192)= 0
open(/usr/lib/sbcl/sbcl-dist.core, O_RDONLY) = 3
read(3, SBCL\0\0\17\24\0\0\0\3\0\0\0\3\0\0\17;\0\0\0!\0\0\0v\0..., 8192) =
8192
mmap(0x1000, 20176896, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x1000
mmap(0x2800, 5267456, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x134) = 0x2800
mmap(0x4000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x1846000) = 0x4000
rt_sigaction(SIGILL, {0x1ca1c, [PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM
PROF WINCH USR1 USR2], SA_RESTART|SA_SIGINFO}, NULL, 0xf7dcb0ec, 3) = 0
rt_sigaction(SIGEMT, {0x1cd1c, [PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM
PROF WINCH USR1 USR2], SA_RESTART|SA_SIGINFO}, NULL, 0xf7dcb0ec, 3) = 0
rt_sigaction(SIGSEGV, {0x1da0c, [PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM
PROF WINCH USR1 USR2], SA_RESTART|SA_SIGINFO}, NULL, 0xf7dcb0ec, 3) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
---8---8---
Thanks,
--
J.P. Larocque is [EMAIL PROTECTED] and [EMAIL PROTECTED]
Encrypted/signed e-mail preferred; http://ely.ath.cx/~piranha/pgp
Fpr 5612 10A8 4986 2D85 A995 252B 4C02 5E02 F61D 2E61; ID 0xF61D2E61
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397067: xscreensaver: Crashes immediately: Failed RRSelectInput on AMD64 with PPC X server
Package: xscreensaver Version: 4.21-3 Severity: normal xscreensaver fails immediately on startup following a failed RRSelectInput request. xscreensaver is running on a Xen AMD64 machine, and the X server is on a remote PPC machine. The X server is x.org X11R7.1, compiled from source. If I knew of a way to disable the RANDR extension without rebuilding the X server, I'd try xscreensaver without it. Below is the output of xscreensaver -sync -verbose -no-capture. ---8---8--- xscreensaver 4.21, copyright (c) 1991-2005 by Jamie Zawinski [EMAIL PROTECTED]. xscreensaver: running as piranha/piranha (1000/1000) xscreensaver: in process 4061. xscreensaver: 14:04:33: 0: xscreensaver-gl-helper: GL visual is 0x24. xscreensaver: 14:04:33: running on display amazing-sounds-of-orgy.thoughtcrime.us:0.0 (1 screen). xscreensaver: 14:04:33: vendor is The X.Org Foundation, 7010. xscreensaver: 14:04:33: useful extensions: xscreensaver: 14:04:33: MIT Screen-Saver -- not supported at compile time! xscreensaver: 14:04:33: Shared Memory xscreensaver: 14:04:33: Double-Buffering xscreensaver: 14:04:33: Power Management xscreensaver: 14:04:33: GLX xscreensaver: 14:04:33: XF86 Video-Mode xscreensaver: 14:04:33: Resize-and-Rotate xscreensaver: 14:04:33: screen 0 non-colormapped depths: 24. xscreensaver: 14:04:33: selecting RANDR events ## xscreensaver: 14:04:33: X Error! PLEASE REPORT THIS BUG. xscreensaver: 14:04:33: screen 0/0: 0x44, 0x0, 0x0 ## X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 154 (RANDR) Minor opcode of failed request: 4 (RRSelectInput) Value in failed request: 0x100 Serial number of failed request: 158 Current serial number in output stream: 159 xscreensaver: 14:04:33: dumping core (because of synchronous X Error) xscreensaver: 14:04:33: see http://www.jwz.org/xscreensaver/bugs.html for bug reporting information. xscreensaver: 14:04:33: current directory is /home/piranha/bugs/xscreensaver xscreensaver: 14:04:33: running as piranha/piranha (1000/1000) ---8---8--- Below is my output from gdb in gathering a stack trace. ---8---8--- GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. Core was generated by `xscreensaver -sync -verbose -no-capture'. Program terminated with signal 6, Aborted. Reading symbols from /usr/X11R6/lib/libXmu.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libXrandr.so.2 Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/X11R6/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/lib/libgdk_pixbuf_xlib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdk_pixbuf_xlib-2.0.so.0 Reading symbols from /usr/lib/libgdk_pixbuf-2.0.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libgobject-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgobject-2.0.so.0 Reading symbols from /usr/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgmodule-2.0.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libglib-2.0.so.0... (no debugging symbols
Bug#394731: mpc: Won't build on The Hurd because of MAXPATHLEN
Package: mpc Version: 0.11.2-2 Severity: important Tags: patch Justification: fails to build from source mpc fails to build on The Hurd because it relies on the macro MAXPATHLEN. This isn't available on The Hurd, because there is no maximum path length on these systems. cc -DHAVE_CONFIG_H -I. -I/home/piranha/build/mpc/mpc-0.11.2/./src -I.. -Wall -g -Wall -O2 -I/usr/include -Wall -g -Wall -O2 -I/usr/include -c `test -f '/home/piranha/build/mpc/mpc-0.11.2/./src/util.c' || echo '/home/piranha/build/mpc/mpc-0.11.2/./src/'`/home/piranha/build/mpc/mpc-0.11.2/./src/util.c /home/piranha/build/mpc/mpc-0.11.2/./src/util.c: In function 'stdinToArgArray': /home/piranha/build/mpc/mpc-0.11.2/./src/util.c:45: error: 'MAXPATHLEN' undeclared (first use in this function) /home/piranha/build/mpc/mpc-0.11.2/./src/util.c:45: error: (Each undeclared identifier is reported only once /home/piranha/build/mpc/mpc-0.11.2/./src/util.c:45: error: for each function it appears in.) /home/piranha/build/mpc/mpc-0.11.2/./src/util.c:45: warning: unused variable 'buffer' make[3]: *** [util.o] Error 1 make[3]: Leaving directory `/home/piranha/build/mpc/mpc-0.11.2/build-dir/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/piranha/build/mpc/mpc-0.11.2/build-dir' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/piranha/build/mpc/mpc-0.11.2/build-dir' make: *** [debian/stamp-makefile-build] Error 2 The following is the only place referencing MAXPATHLEN: mpc-0.11.2/src/mpc.h:25:#define STRING_LENGTH (2*MAXPATHLEN) STRING_LENGTH is used exclusively in util.c, function stdinToArgArray(). Here, it is used as the buffer size and maximum line length for fgets() calls, reading commands from stdin. (Reading commands from standard input seems to be an undocumented feature of mpc.) There are no comments justifying STRING_LENGTH. The name of this macro doesn't communicate an intrinsic relationship with filesystem path lengths. It seems somewhat arbitrary. Therefore, --8--8-- diff -ur mpc-0.11.2-orig/src/mpc.h mpc-0.11.2/src/mpc.h --- mpc-0.11.2-orig/src/mpc.h 2005-03-11 01:04:35.0 -0800 +++ mpc-0.11.2/src/mpc.h2006-10-21 23:16:59.0 -0700 @@ -22,7 +22,7 @@ #include ../config.h #include libmpdclient.h -#define STRING_LENGTH (2*MAXPATHLEN) +#define STRING_LENGTH (16384) /* This is arbitrary. */ #define STDIN_SYMBOL - --8--8-- This lets it build on The Hurd, and cursory testing shows that it works correctly. The proper solution would be to avoid maximum line-lengths. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: hurd-i386 (i686-AT386) Shell: /bin/sh linked to /bin/bash Kernel: GNU-Mach 1.3/Hurd-0.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mpc depends on: ii libc0.3 2.3.6.ds1-5 GNU C Library: Shared libraries mpc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394775: Sparc64 install fails: 'sbcl.sh install-clc' segfaults
Package: sbcl Version: 1:0.8.16-1 Severity: important I cannot install sbcl on a Sun Ultra 1. sbcl crashes during package configuration. The package isn't even marked as broken. ---8---8--- Selecting previously deselected package common-lisp-controller. (Reading database ... 43010 files and directories currently installed.) Unpacking common-lisp-controller (from .../common-lisp-controller_4.15sarge3_all.deb) ... Setting up common-lisp-controller (4.15sarge3) ... Selecting previously deselected package sbcl. (Reading database ... 43034 files and directories currently installed.) Unpacking sbcl (from .../sbcl_1%3a0.8.16-1_sparc.deb) ... Setting up sbcl (0.8.16-1) ... /usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc. /usr/lib/common-lisp/bin/sbcl.sh: line 58: 12442 Segmentation fault (core dumped) sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --userinit /dev/null --load /usr/lib/sbcl/install-clc.lisp 2/dev/null mv: cannot stat `sbcl-new.core': No such file or directory FAILED Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done ---8---8--- I read some old bug report leading me to believe that my locale could be a problem for SBCL. The above output is with LC_ALL=C and LANG=C on the environment. The stack trace produced below probably doesn't convey any meaningful information. ---8---8--- $ sudo gdb sbcl /usr/lib/sbcl/core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc-linux...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. Core was generated by `sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --us'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x000189f8 in handle_control_stack_guard_triggered () (gdb) bt #0 0x000189f8 in handle_control_stack_guard_triggered () #1 0x0001da80 in os_install_interrupt_handlers () #2 0x0001da80 in os_install_interrupt_handlers () Previous frame identical to this frame (corrupt stack?) ---8---8--- Attempts to use sbcl: ---8---8--- $ sbcl This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped) ---8---8--- ---8---8--- $ gdb sbcl GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc-linux...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/bin/sbcl (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Program received signal SIGSEGV, Segmentation fault. 0x0001516c in alloc_base_string () (gdb) bt #0 0x0001516c in alloc_base_string () #1 0x0001abb8 in main () ---8---8--- Please let me know if I can be of any help. -- System Information: Debian Release: 3.1 Architecture: sparc (sparc64) Kernel: Linux 2.6.18 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages sbcl depends on: ii common-lisp-controlle 4.15sarge3 This is a Common Lisp source and c ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- no debconf information -- J.P. Larocque is [EMAIL PROTECTED] and [EMAIL PROTECTED] Encrypted/signed e
Bug#379406: radvd: Crashes on SIGHUP with can't join ipv6-allrouters on iface and bogus syntax error
Package: radvd
Version: 1:0.7.3-1
Severity: normal
According to radvd.conf(5), I can configure radvd to continue if a
particular interface is unavailable at start time (IgnoreIfMissing).
In the case that it becomes available, I should arrange to have radvd
receive SIGHUP.
This message is logged when I try /etc/init.d/radvd reload:
Jul 23 03:31:30 turing radvd[22317]: attempting to reread config file
Jul 23 03:31:30 turing radvd[22317]: can't join ipv6-allrouters on eth-apo
Jul 23 03:31:30 turing radvd[22317]: syntax error in config file:
/etc/radvd.conf
What strikes me as odd is that I hadn't modified radvd.conf between
the times that I started it and sent it SIGHUP. If there was a syntax
error, shouldn't it have bombed on startup?
This system in particular is a little esoteric; it's x86_64, has -
in all interface names, and runs Xen. A recipe for disaster, I must
concede.
I installed the same version--the latest available in Sarge--on an
i386 host. I took a fragment of my original radvd.conf and reduced it
to the following:
interface eth0
{
AdvSendAdvert on;
prefix 2002:c6ca:19fb:800::/64
{
};
};
This is very close to the distributed simple example configuration
file:
--- /usr/share/doc/radvd/examples/simple-radvd.conf 2005-02-22
11:01:32.0 -0800
+++ /etc/radvd.conf 2006-07-23 03:39:27.0 -0700
@@ -1,7 +1,7 @@
interface eth0
{
AdvSendAdvert on;
- prefix 2001:db8::/32
+ prefix 2002:c6ca:19fb:800::/64
{
};
};
Again, it starts, but still insists there must be a syntax error when
it gets SIGHUP:
$ sudo radvd -m stderr -d 4
[Jul 23 03:59:22] radvd: version 0.7.3 started
[Jul 23 03:59:22] radvd: inet_pton returned 1
[Jul 23 03:59:22] radvd: hardware type for eth0 is 1
[Jul 23 03:59:22] radvd: link layer token length for eth0 is 48
[Jul 23 03:59:22] radvd: prefix length for eth0 is 64
[Jul 23 03:59:22] radvd: interface definition for eth0 is ok
[Jul 23 03:59:22] radvd: sending RA on eth0
[Jul 23 03:59:22] radvd: setting timer: 600.00 secs
[Jul 23 03:59:22] radvd: calling alarm: 599 secs, 43 usecs
[Jul 23 03:59:22] radvd: recvmsg len=56
[Jul 23 03:59:22] radvd: if_index 3
[Jul 23 03:59:22] radvd: found Interface: eth0
SIGHUP sent to this process
[Jul 23 03:59:37] radvd: sighup_handler called
[Jul 23 03:59:37] radvd: attempting to reread config file
[Jul 23 03:59:37] radvd: reopening log
[Jul 23 03:59:37] radvd: disabling timer for eth0
[Jul 23 03:59:37] radvd: freeing interface eth0
[Jul 23 03:59:37] radvd: inet_pton returned 1
[Jul 23 03:59:37] radvd: hardware type for eth0 is 1
[Jul 23 03:59:37] radvd: link layer token length for eth0 is 48
[Jul 23 03:59:37] radvd: prefix length for eth0 is 64
[Jul 23 03:59:37] radvd: can't join ipv6-allrouters on eth0
[Jul 23 03:59:37] radvd: syntax error in config file: /etc/radvd.conf
The message can't join ipv6-allrouters seems fairly unusual. I
found very few references to it on the WWW, other than a reference to
a bug in an old version.
On a hunch, I realized I'd seen ipv6-allrouters somewhere before.
Something similar is listed in /etc/hosts:
ff02::2 ip6-allrouters
I tried adding ipv6-allrouters as an alias, at the end of that line,
but got the same result.
In closing, they don't call it stateless autoconfiguration for
nothing: my workaround is to simply restart radvd whenever an
interface state changes. No messages regarding ipv6-allrouters. No
bogus syntax errors. IgnoreIfMissing does prove to work--it starts,
even if an interface is unavailable, and hosts on the network are
picking up autoconfigured addresses.
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16.13-xen
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages radvd depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
-- no debconf information
--
J.P. Larocque is [EMAIL PROTECTED] and [EMAIL PROTECTED]
Encrypted/signed e-mail preferred; http://ely.ath.cx/~piranha/pgp
Fpr 5612 10A8 4986 2D85 A995 252B 4C02 5E02 F61D 2E61; ID 0xF61D2E61
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
