GNU bug report logs - #72025
SEGFAULT when using corfu and lsp-mode with clangd

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72025 in the body.
You can then email your comments to 72025 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ravi D'Elia <ravijdelia <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: SEGFAULT when using corfu and lsp-mode with clangd
Date: Tue, 9 Jul 2024 19:20:15 -0400

[Message part 1 (text/plain, inline)]

At unpredictable times while editing c++ files, emacs will segfault.
I haven't been able to reproduce without lsp-mode, but with how
unpredictable this is I don't think that necessarily means much.
The problem exists with and without native compilation- this
report assumes without.

STEPS TO REPRODUCE:
- Let '~/minimal' contain the attached init file
- Start emacs with 'emacs --init-directory ~/minimal'
- Open a c++ file
- Edit it, taking care to type quickly and go back to edit within
  words. I can usually get a crash within 10 minutes, but I haven't
  been able to iterate enough to figure out exactly what is
  happening. It's always while typing though, I think in response
  to a keydown.

Attached is the init file I used to reproduce this, and the backtrace.
I had issues with the .gdbinit, which I will hopefully address when
I get back from vacation.

Below is the information from report-emacs-bug:

In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42,
cairo version 1.18.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Arch Linux

Configured using:
 'configure --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib
 --with-tree-sitter --localstatedir=/var --with-cairo
 --disable-build-details --with-harfbuzz --with-libsystemd
 --with-modules --with-x-toolkit=gtk3 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3
 -Wformat -Werror=format-security -fstack-clash-protection
 -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g
 -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
 -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  corfu-echo-mode: t
  global-corfu-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/xscheme hides /usr/share/emacs/29.4/lisp/progmodes/xscheme

Features:
(shadow sort mail-extr emacsbug message yank-media dired dired-loaddefs
rfc822 mml mml-sec epa derived gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils flymake-cc time-date
flymake-proc flymake warnings lsp-diagnostics lsp-headerline lsp-icons
lsp-modeline lsp-lens view lsp-zig lsp-yang lsp-yaml lsp-xml lsp-wgsl
lsp-volar lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala
lsp-v lsp-typeprof lsp-ttcn3 lsp-trunk lsp-toml lsp-tilt lsp-tex
lsp-terraform lsp-svelte lsp-steep lsp-sqls lsp-sql lsp-sorbet
lsp-solidity lsp-solargraph lsp-semgrep lsp-rust lsp-ruff-lsp
lsp-ruby-syntax-tree lsp-ruby-lsp lsp-rubocop lsp-roslyn lsp-rf
lsp-remark lsp-racket lsp-r lsp-qml lsp-pylsp lsp-pyls lsp-pwsh
lsp-purescript lsp-pls lsp-php lsp-perlnavigator lsp-perl lsp-openscad
lsp-ocaml lsp-nushell lsp-nix lsp-nim lsp-nginx lsp-move lsp-mojo
lsp-mint lsp-meson lsp-mdx lsp-marksman lsp-markdown lsp-magik lsp-lua
lsp-lisp lsp-kotlin lsp-json lsp-jq lsp-javascript lsp-idris lsp-haxe
lsp-hack lsp-groovy lsp-graphql lsp-golangci-lint lsp-glsl lsp-gleam
lsp-gdscript lsp-fsharp lsp-fortran lsp-eslint lsp-erlang lsp-emmet
lsp-elm lsp-elixir lsp-earthly lsp-dockerfile lsp-dhall lsp-d lsp-cypher
lsp-cucumber lsp-css lsp-csharp gnutls lsp-crystal lsp-credo lsp-cobol
lsp-cmake lsp-clojure lsp-clangd dom lsp-bufls lsp-go lsp-completion
lsp-beancount lsp-bash lsp-awk lsp-autotools lsp-astro lsp-asm
lsp-ansible lsp-angular lsp-ada lsp-semantic-tokens lsp-actionscript
lsp-mode lsp-protocol xref project tree-widget wid-edit spinner pcase
network-stream puny nsm markdown-mode rx color thingatpt noutline
outline icons lv inline imenu ht filenotify f s ewoc epg rfc6068
epg-config dash compile text-property-search comint ansi-osc ansi-color
ring cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs corfu-echo corfu compat compat-30 cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core corfu-autoloads compat-autoloads lsp-mode-autoloads
ht-autoloads f-autoloads info dash-autoloads lv-autoloads
markdown-mode-autoloads s-autoloads spinner-autoloads package browse-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 203184 12765)
 (symbols 48 23270 0)
 (strings 32 74270 2672)
 (string-bytes 1 2204500)
 (vectors 16 48780)
 (vector-slots 8 757848 20048)
 (floats 8 190 29)
 (intervals 56 799 0)
 (buffers 984 16))

[init.el (text/plain, attachment)]

[bt-full (text/plain, attachment)]

Message #8 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Ravi D'Elia <ravijdelia <at> gmail.com>
Cc: 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 04:06:02 -0400

Ravi D'Elia <ravijdelia <at> gmail.com> writes:

> At unpredictable times while editing c++ files, emacs will segfault.
> I haven't been able to reproduce without lsp-mode, but with how
> unpredictable this is I don't think that necessarily means much.
> The problem exists with and without native compilation- this
> report assumes without.
>
> STEPS TO REPRODUCE:
> - Let '~/minimal' contain the attached init file
> - Start emacs with 'emacs --init-directory ~/minimal'
> - Open a c++ file
> - Edit it, taking care to type quickly and go back to edit within
>   words. I can usually get a crash within 10 minutes, but I haven't
>   been able to iterate enough to figure out exactly what is
>   happening. It's always while typing though, I think in response
>   to a keydown.
>
> Attached is the init file I used to reproduce this, and the backtrace.
> I had issues with the .gdbinit, which I will hopefully address when
> I get back from vacation.
>

Hi Ravi,

thanks for reporting, how did you produce the stack trace?  I ask
because without function names in it is not very useful.

Here we have some information on how to process backtraces when Emacs
crashes [1] and here [2] some info on how to run Emacs under gdb (and
produce the backtrace there).

Probably debugging Emacs under gdb would be the best option here.

Thanks

  Andrea

[1] <https://www.gnu.org/software/emacs/manual/html_node/emacs/Crashing.html>
[2] <https://www.gnu.org/software/emacs/manual/html_node/emacs/Checklist.html#Checklist>

Message #11 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: ravijdelia <at> gmail.com, 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 14:57:23 +0300

> Cc: 72025 <at> debbugs.gnu.org
> From: Andrea Corallo <acorallo <at> gnu.org>
> Date: Wed, 10 Jul 2024 04:06:02 -0400
> 
> Ravi D'Elia <ravijdelia <at> gmail.com> writes:
> 
> > At unpredictable times while editing c++ files, emacs will segfault.
> > I haven't been able to reproduce without lsp-mode, but with how
> > unpredictable this is I don't think that necessarily means much.
> > The problem exists with and without native compilation- this
> > report assumes without.
> >
> > STEPS TO REPRODUCE:
> > - Let '~/minimal' contain the attached init file
> > - Start emacs with 'emacs --init-directory ~/minimal'
> > - Open a c++ file
> > - Edit it, taking care to type quickly and go back to edit within
> >   words. I can usually get a crash within 10 minutes, but I haven't
> >   been able to iterate enough to figure out exactly what is
> >   happening. It's always while typing though, I think in response
> >   to a keydown.
> >
> > Attached is the init file I used to reproduce this, and the backtrace.
> > I had issues with the .gdbinit, which I will hopefully address when
> > I get back from vacation.
> >
> 
> Hi Ravi,
> 
> thanks for reporting, how did you produce the stack trace?  I ask
> because without function names in it is not very useful.
> 
> Here we have some information on how to process backtraces when Emacs
> crashes [1] and here [2] some info on how to run Emacs under gdb (and
> produce the backtrace there).
> 
> Probably debugging Emacs under gdb would be the best option here.

I think he already ran Emacs from GDB, but his Emacs is stripped of
debugging symbols, so GDB couldn't display anything useful.  So the
procedures you mention will not help.  What _would_ help is rebuilding
Emacs with debug info, or downloading the debug info from the distro
where you got the Emacs binaries.

Message #14 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ravijdelia <at> gmail.com, 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 10:07:28 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 72025 <at> debbugs.gnu.org
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Date: Wed, 10 Jul 2024 04:06:02 -0400
>> 
>> Ravi D'Elia <ravijdelia <at> gmail.com> writes:
>> 
>> > At unpredictable times while editing c++ files, emacs will segfault.
>> > I haven't been able to reproduce without lsp-mode, but with how
>> > unpredictable this is I don't think that necessarily means much.
>> > The problem exists with and without native compilation- this
>> > report assumes without.
>> >
>> > STEPS TO REPRODUCE:
>> > - Let '~/minimal' contain the attached init file
>> > - Start emacs with 'emacs --init-directory ~/minimal'
>> > - Open a c++ file
>> > - Edit it, taking care to type quickly and go back to edit within
>> >   words. I can usually get a crash within 10 minutes, but I haven't
>> >   been able to iterate enough to figure out exactly what is
>> >   happening. It's always while typing though, I think in response
>> >   to a keydown.
>> >
>> > Attached is the init file I used to reproduce this, and the backtrace.
>> > I had issues with the .gdbinit, which I will hopefully address when
>> > I get back from vacation.
>> >
>> 
>> Hi Ravi,
>> 
>> thanks for reporting, how did you produce the stack trace?  I ask
>> because without function names in it is not very useful.
>> 
>> Here we have some information on how to process backtraces when Emacs
>> crashes [1] and here [2] some info on how to run Emacs under gdb (and
>> produce the backtrace there).
>> 
>> Probably debugging Emacs under gdb would be the best option here.
>
> I think he already ran Emacs from GDB, but his Emacs is stripped of
> debugging symbols, so GDB couldn't display anything useful.  So the
> procedures you mention will not help.

Right, do you we if typically distros strip our binary and this is
probably the case?

  Andrea

Message #17 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: ravijdelia <at> gmail.com, 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 17:37:33 +0300

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: ravijdelia <at> gmail.com,  72025 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2024 10:07:28 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: 72025 <at> debbugs.gnu.org
> >> From: Andrea Corallo <acorallo <at> gnu.org>
> >> Date: Wed, 10 Jul 2024 04:06:02 -0400
> >> 
> >> Ravi D'Elia <ravijdelia <at> gmail.com> writes:
> >> 
> >> > At unpredictable times while editing c++ files, emacs will segfault.
> >> > I haven't been able to reproduce without lsp-mode, but with how
> >> > unpredictable this is I don't think that necessarily means much.
> >> > The problem exists with and without native compilation- this
> >> > report assumes without.
> >> >
> >> > STEPS TO REPRODUCE:
> >> > - Let '~/minimal' contain the attached init file
> >> > - Start emacs with 'emacs --init-directory ~/minimal'
> >> > - Open a c++ file
> >> > - Edit it, taking care to type quickly and go back to edit within
> >> >   words. I can usually get a crash within 10 minutes, but I haven't
> >> >   been able to iterate enough to figure out exactly what is
> >> >   happening. It's always while typing though, I think in response
> >> >   to a keydown.
> >> >
> >> > Attached is the init file I used to reproduce this, and the backtrace.
> >> > I had issues with the .gdbinit, which I will hopefully address when
> >> > I get back from vacation.
> >> >
> >> 
> >> Hi Ravi,
> >> 
> >> thanks for reporting, how did you produce the stack trace?  I ask
> >> because without function names in it is not very useful.
> >> 
> >> Here we have some information on how to process backtraces when Emacs
> >> crashes [1] and here [2] some info on how to run Emacs under gdb (and
> >> produce the backtrace there).
> >> 
> >> Probably debugging Emacs under gdb would be the best option here.
> >
> > I think he already ran Emacs from GDB, but his Emacs is stripped of
> > debugging symbols, so GDB couldn't display anything useful.  So the
> > procedures you mention will not help.
> 
> Right, do you we if typically distros strip our binary and this is
> probably the case?

I don't know if this is the rule (I think the rule is to offer a
separate package with debug info, and if GDB supports debuginfod
servers, it can download the debug info at the beginning of a
session).  But clearly in this case the binary was stripped by
someone.

Message #20 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Ravi D'Elia <ravijdelia <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andrea Corallo <acorallo <at> gnu.org>, 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 11:27:00 -0400

On 24/07/10 05:37PM, Eli Zaretskii wrote:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: ravijdelia <at> gmail.com,  72025 <at> debbugs.gnu.org
>> Date: Wed, 10 Jul 2024 10:07:28 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Cc: 72025 <at> debbugs.gnu.org
>> >> From: Andrea Corallo <acorallo <at> gnu.org>
>> >> Date: Wed, 10 Jul 2024 04:06:02 -0400
>> >>
>> >> Ravi D'Elia <ravijdelia <at> gmail.com> writes:
>> >>
>> >> > At unpredictable times while editing c++ files, emacs will segfault.
>> >> > I haven't been able to reproduce without lsp-mode, but with how
>> >> > unpredictable this is I don't think that necessarily means much.
>> >> > The problem exists with and without native compilation- this
>> >> > report assumes without.
>> >> >
>> >> > STEPS TO REPRODUCE:
>> >> > - Let '~/minimal' contain the attached init file
>> >> > - Start emacs with 'emacs --init-directory ~/minimal'
>> >> > - Open a c++ file
>> >> > - Edit it, taking care to type quickly and go back to edit within
>> >> >   words. I can usually get a crash within 10 minutes, but I haven't
>> >> >   been able to iterate enough to figure out exactly what is
>> >> >   happening. It's always while typing though, I think in response
>> >> >   to a keydown.
>> >> >
>> >> > Attached is the init file I used to reproduce this, and the backtrace.
>> >> > I had issues with the .gdbinit, which I will hopefully address when
>> >> > I get back from vacation.
>> >> >
>> >>
>> >> Hi Ravi,
>> >>
>> >> thanks for reporting, how did you produce the stack trace?  I ask
>> >> because without function names in it is not very useful.
>> >>
>> >> Here we have some information on how to process backtraces when Emacs
>> >> crashes [1] and here [2] some info on how to run Emacs under gdb (and
>> >> produce the backtrace there).
>> >>
>> >> Probably debugging Emacs under gdb would be the best option here.
>> >
>> > I think he already ran Emacs from GDB, but his Emacs is stripped of
>> > debugging symbols, so GDB couldn't display anything useful.  So the
>> > procedures you mention will not help.
>>
>> Right, do you we if typically distros strip our binary and this is
>> probably the case?
>
>I don't know if this is the rule (I think the rule is to offer a
>separate package with debug info, and if GDB supports debuginfod
>servers, it can download the debug info at the beginning of a
>session).  But clearly in this case the binary was stripped by
>someone.

Sorry about the backtrace, I did indeed use gdb but didn't have
the debugging symbols to make it useful. My distro (arch) does
ship a stripped binary with a separate debug package but I'm having
difficulties due to (I think) some packaging mishap on my end.  While
I take that up on my distro's forum, I'm going to try and build with
debugging info. I'll send in the backtrace when one of these bears
fruit. Didn't expect to have my computer on me, otherwise I would have
figured this out first.

Message #23 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Ravi D'Elia <ravijdelia <at> gmail.com>
To: 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Wed, 10 Jul 2024 20:18:56 -0400

On 24/07/10 11:27AM, Ravi D'Elia wrote:
>Sorry about the backtrace, I did indeed use gdb but didn't have
>the debugging symbols to make it useful. My distro (arch) does
>ship a stripped binary with a separate debug package but I'm having
>difficulties due to (I think) some packaging mishap on my end.  While
>I take that up on my distro's forum, I'm going to try and build with
>debugging info. I'll send in the backtrace when one of these bears
>fruit. Didn't expect to have my computer on me, otherwise I would have
>figured this out first.

Well after a day of trying I have found a very robust solution to the
problem- include debug symbols in any way whatsoever. I have failed to
replicate with an emacs binary built with any combination of flags and
settings. I have failed to replicate with what should be an exact rebuild
of Arch's package. The only way I get the error is by reinstalling from
repos. So I'm calling it, I'll just use the working build for now. Since
that build has debug symbols it will be easy to get some useful data if
the problem strikes again, but for now there isn't much to do. Thanks
for the help, sorry I couldn't do more.

Message #26 received at 72025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ravi D'Elia <ravijdelia <at> gmail.com>
Cc: 72025 <at> debbugs.gnu.org
Subject: Re: bug#72025: SEGFAULT when using corfu and lsp-mode with clangd
Date: Thu, 11 Jul 2024 07:55:23 +0300

tags 72025 unreproducible
close 72025
thanks

> Date: Wed, 10 Jul 2024 20:18:56 -0400
> From: Ravi D'Elia <ravijdelia <at> gmail.com>
> 
> On 24/07/10 11:27AM, Ravi D'Elia wrote:
> >Sorry about the backtrace, I did indeed use gdb but didn't have
> >the debugging symbols to make it useful. My distro (arch) does
> >ship a stripped binary with a separate debug package but I'm having
> >difficulties due to (I think) some packaging mishap on my end.  While
> >I take that up on my distro's forum, I'm going to try and build with
> >debugging info. I'll send in the backtrace when one of these bears
> >fruit. Didn't expect to have my computer on me, otherwise I would have
> >figured this out first.
> 
> Well after a day of trying I have found a very robust solution to the
> problem- include debug symbols in any way whatsoever. I have failed to
> replicate with an emacs binary built with any combination of flags and
> settings. I have failed to replicate with what should be an exact rebuild
> of Arch's package. The only way I get the error is by reinstalling from
> repos. So I'm calling it, I'll just use the working build for now. Since
> that build has debug symbols it will be easy to get some useful data if
> the problem strikes again, but for now there isn't much to do. Thanks
> for the help, sorry I couldn't do more.

Thank you very much for your efforts.

I'm therefore closing this bug as unreproducible.  If you ever bump
into it again, we can always reopen the bug with the details you
hopefully will be able to provide then.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.