Bug#708256: Does this autofs bug also happen with a i386 kernel
On Mon, 19 Aug 2013 10:55:38 +0200, Reinhard Tartler siret...@gmail.com said: from your logs, I notice that you are running an i386 userland with amd64 kernel. Can you confirm the segfaults also with a non-mixed setup, that is, a i386 kernel with i386 userland, or an amd64 kernel with amd64 userland? With a non-mixed setup, there is no problem. Thanks, --John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557960: slang 2.2.4 crash under newt in Debian
On Sun, 04 Dec 2011 20:03:28 +, Alastair McKinstry mckins...@debian.org said: I have a strange crash in slang which i'm trying to debug and maybe you can help. [...] It appears screen is not needed; just TERM=screen will trigger it, TERM=xterm will not. sltermin.c:256 is freeing t-string_table for the terminfo, which to my untutored eyes looks valid in both cases. I would try running it under valgrind to see if that gives any hints. I see nothing wrong with the slang code. Thanks, --John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602975: procmeter3 (3.5c-1) SEGVs upon startup
Package: procmeter3
Version: 3.5c-1
Severity: grave
I am running an up-to-date Debian squeeze 64 system. procmeter3 SEGVs
right away upon startup:
$ procmeter3
zsh: segmentation fault procmeter3
I have no .procmeterrc file. I suggested a severity of grave
because the SEGV makes it unusable.
gdb indicates that it is failing in
/usr/lib/X11/ProcMeter3/modules/stat-intr.so:
$ gdb procmeter3
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
[...]
Reading symbols from /usr/bin/procmeter3...(no debugging symbols
found)...done.
(gdb) run
Starting program: /usr/bin/procmeter3
Program received signal SIGBUS, Bus error.
0x747adfcb in Initialise ()
from /usr/lib/X11/ProcMeter3/modules/stat-intr.so
(gdb) where
#0 0x747adfcb in Initialise ()
from /usr/lib/X11/ProcMeter3/modules/stat-intr.so
#1 0x0040a311 in LoadModule ()
#2 0x0040a8c8 in LoadAllModules ()
#3 0x0040b3d0 in main ()
strace shows that this happens when reading /proc/interrupts:
[...]
open(/proc/interrupts, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f548bd6e000
read(6, CPU0 CPU1 ..., 1024) = 1024
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Here is some info about the system:
$ uname -a
Linux aluche 2.6.32-5-amd64 #1 SMP Fri Oct 15 00:56:30 UTC 2010 x86_64
GNU/Linux
$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 14 Nov 9 15:39 /lib/libc.so.6 - libc-2.11.2.so*
$ ls -ld /lib64
lrwxrwxrwx 1 root root 4 Jul 27 16:01 /lib64 - /lib/
$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12
CPU13 CPU14 CPU15
0: 4387 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-edge timer
1: 2 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-edge i8042
8: 1 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-edge rtc0
9: 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi acpi
12: 4 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-edge i8042
16: 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi uhci_hcd:usb3
18: 82581 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb8
19: 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb7
21: 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi uhci_hcd:usb4
22:604 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi HDA Intel
23: 264051 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6
30: 3 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-IO-APIC-fasteoi nouveau
48: 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 DMAR_MSI-edge dmar0
59: 10072896 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 IR-PCI-MSI-edge eth0-rx-0
60:
Bug#572621: ispell mode break original ispell mode from jed
On Thu, 3 Jun 2010 11:29:29 +0200, Paul Boekholt p.boekh...@gmail.com said: Anyway, I think the -a option should not be in the variable. Emacs' ispel= l mode has had an ispell-program-name without -a for at least 13 years, an= d my version has used it for 7 years. Users who have customized it and switch to jed's ispell will have problems. I think that the -a has to go somewhere, otherwise ispell does not work for me. In fact, if I use: echo foood | ispell then I get a usage message. I see that flyspell.sl adds the -a when starting the flyspell process. If Ispell_Program_Name already contains -a, then multiple -a values do not seem to hurt. So it seems that loading ispell.sl first before flyspell.sl should work. It may not work the other way around, but it is unclear to me why one would do that. Thanks, --John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#446444: Wrong key definition in rxvt-unicode terminfo file
Package: ncurses-base
Version: 5.5-5
The rxvt-unicode terminfo file indicates that the escape sequence is
ESC 2 $. This can be seen using `infocmp`:
# Reconstructed via infocmp from file: /lib/terminfo/r/rxvt-unicode
rxvt-unicode|rxvt-unicode terminal (X Window System),
am, bce, bw, ccc, eo, km, mc5i, mir, msgr, npc, xenl, xon,
[...]
kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E2$, kLFT=\E[d,
However, the rxvt-unicode source code file command.C says it should
be \E[2$. Here is the code:
void
rxvt_term::key_press (XKeyEvent ev)
{
[...]
switch (keysym)
{
/* normal XTerm key bindings */
[...]
case XK_Insert:
strcpy (kbuf, \033[2~);
break;
[...]
/*
* these modifications only affect the static keybuffer
* pass Shift/Control indicators for function keys ending with `~'
*
* eg,
* Prior = ESC[5~
* Shift+Prior = ESC[5$
* Ctrl+Prior = ESC[5^
* Ctrl+Shift+Prior = ESC[5@
* Meta adds an Escape prefix (with META8_OPTION, if meta == escape).
*/
if (kbuf[0] == C0_ESC kbuf[1] == '[' kbuf[len - 1] == '~')
kbuf[len - 1] = (shft ? (ctrl ? '@' : '$') : (ctrl ? '^' : '~'));
The last bit of code turns the ~ into a $.
The bug is also in the sid version of the file. I am using etch.
Thanks,
--John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427166: jed: compiled against S-Lang 20007 but linked to 20006
On Sun, 3 Jun 2007 18:42:40 +0200, Jörg Sommer [EMAIL PROTECTED] said: jed works properly, except it starts with the warning =20 ***Warning: Executable compiled against S-Lang 20007 but linked to 20006 Why did you add this check to main? Do you have any reason to recommend an update? Because it adds a sleep of two seconds I tend to remove it =66rom the Debian package. Do you think this causes any problems? I think such a reverts the advantage of shared libraries to upgrade the library without recompiling the program. But that is not what the message indicates. It says that it was compiled against a newer version of the library (20007) but actually using an older version (20006). So something is wrong with the linker configuration. Also suppose that 20007 contains a bug fix that was not in 20006 and that jed included a work-around if compiled against older versions of the library: /* Some jed code */ #if SLANG_VERSION 20007 /* work around a bug to avoid a SEGV */ . . #else /* no need to work around the bug */ #endif As you can see, when compiled against 20007, the bug-fixing code will not get included. However, since the user is actually using 20006, the bug is present but the code to work-around it is not. I hope this explains why I feel that the code should be left there. Thanks, --John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427166: jed: compiled against S-Lang 20007 but linked to 20006
On Sun, 3 Jun 2007 21:00:01 +0200, Rafael Laboissiere [EMAIL PROTECTED] said:
In order to circumvent this problem, we could force jed in Debian to depend
on libslang2 (= 2.0.7). For now, the jed package depends on libslang2 (=
It seems to me that if jed was compiled against 2.0.7, then the depend
ought to be = 2.0.7.
$ cat /var/lib/dpkg/info/libslang2.shlibs
libslang 2 libslang2 (= 2.0.6-3)
Should we ask the slang2 maintainer to bump the version number of the shlibs
file?
You mean to = 2.0.7?
[...]
As you can see, when compiled against 20007, the bug-fixing code
will not get included. However, since the user is actually using
20006, the bug is present but the code to work-around it is not.
This strategy is problematic due to the soname-based behavior of the linker
as I described above. You could replace the conditional compilation above
by some run-time test on the library version. That would be less efficient,
though.
Also in addition to bug fixes, newer versions generally include new
intrinsics and new functionality. While I maintain backward
compatibility and make no claims about forward compatibility. For
example, slang-2.0.7 added several SLfile_*_method functions to the
API. Although in this case, jed did not make use of those functions,
I could imagine code in jed such as
#if SLANG_VERSION = 20007
int some_function ()
{
.
SLfile_set_write_method (...);
.
}
#endif
This is something that I do not believe can be handled at run-time,
and if used with an older version would fail during link-time.
--John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426355: libonig SEGV when using UTF-8 encoding
Package: libonig-dev
Version: 5.2.0-1
Severity: grave
The following (see below) simple C program produces a SEGV in
onig_new. To see this, compile the code using, e.g.,
gcc bug.c -lonig
and then run it:
./a.out
On my debian etch system, I see:
Segmentation fault (core dumped)
I set the severity level to grave because this bug makes the library
unusable to me.
Valgrind shows where the error occurs:
==1902== Invalid read of size 4
==1902==at 0x43F0025: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x4402089: onigenc_unicode_apply_all_case_fold (in
/usr/lib/libonig.so.2.0.0)
==1902==by 0x43F09AD: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F1A1D: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F1B18: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F171E: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F1A1D: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F1B18: (within /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F1CEE: onig_parse_make_tree (in /usr/lib/libonig.so.2.0.0)
==1902==by 0x43F8921: onig_compile (in /usr/lib/libonig.so.2.0.0)
Here is the code to bug.c:
#include stdio.h
#include stdlib.h
#include string.h
#include oniguruma.h
int main (int argc, char **argv)
{
const UChar *pattern;
OnigErrorInfo err_info;
int status;
regex_t *re;
int i;
for (i = 0; i 2; i++)
{
pattern = (UChar *) (?i)[a-z][a-z]+;
status = onig_new (re, pattern, pattern + strlen ((char *)pattern),
ONIG_OPTION_NONE, ONIG_ENCODING_UTF8,
ONIG_SYNTAX_PERL, err_info);
onig_free (re);
if (status != ONIG_NORMAL)
{
fprintf (stderr, onig_new failed\n);
return 1;
}
}
return 0;
}
Thanks,
--John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387061: Highlight on search
Rafael Laboissiere [EMAIL PROTECTED] wrote: I am forwarding below a bug report filed against the jed Debian package b= y This feature was added to jed 0.99.19-24 a while back. Thanks, --John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#211217: most: Fixed UTF-8 output
On Mon, 5 Dec 2005 10:39:46 -0500, Benj. Mako Hill [EMAIL PROTECTED] said: UTF-8 enabled Most, with working (and enabled by default during build) UTF-8 compliant RegExp searches. Wonderful! I've test out the patch and it works great on my system. I've applied it in whole. While it is a good start for UTF-8, it will require more work to integrate. For example, the patch to buffer.c:forward_columns does not appear to properly handle tab characters, embedded backspaces, etc. Such backspaces are used by manpages to simulate an overstrike, underline, etc, e.g., This is B\bBO\bOL\bLD\bD This is BOLD\rBOLD This is U\b_N\b_D\b_E\b_R\b_L\b_I\b_N\b_E\b_D\b_ Accounting for such constructs greatly complicate searches, etc. I welcome the new manpage format that use ANSI escape sequences but I do not know how widespread their use is. Thanks, --John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#211217: most: Fixed UTF-8 output
On Mon, 05 Dec 2005 14:21:43 -0300, Javier Kohen [EMAIL PROTECTED] said: I'll get back to you with a patch on top of most 4.10.2-2 soon, probably tonight. I appreciate it. Thanks, --John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337304: [Fwd: Bug#337304: Floating point exception in SLang_init_all() on alpha]
On Thu, 03 Nov 2005 20:58:32 +, Alastair McKinstry [EMAIL PROTECTED] said: ELF_CC = $(CC) ELF_LINK = $(CC) $(LDFLAGS) -shared -Wl,-soname The problem is that the build process is using: /usr/bin/make -C build-tree/slang-2.0.4 CFLAGS=-g -O2 -fno-strength-reduce -D_R EENTRANT -D_XOPEN_SOURCE=500 \ MODULE_INSTALL_DIR=/usr/lib/slang/v2/modules RPATH= \ install_doc_dir=/usr/share/doc/libslang2 all instead of the value of the CFLAGS given by the configure scripts. On the alpha, -mieee should be added. --John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310086: most: Scroll wheel support
On Sat, 21 May 2005 13:20:02 -0300, Javier Kohen [EMAIL PROTECTED] said: I posted a wishlist request to Debian's BTS regarding a feature I'd like to see in most. Could you please check the report at http://bugs.debian.org/310086 ? Most runs in a terminal window-- it is not an X program. So adding direct support for a wheel mouse is not possible for such an environment. On the other hand, the xserver can be configured recognize the scroll mouse and generate events for it. I believe that xterm can be configured to generate escape sequence for such events via its XTerm*VT100.Translations resource. If so, should should be able to bind these key sequences to the page-up/down commands in most. See the most man page for a description of the setkey functions. --John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
