GNU bug report logs - #58104
29.0.50; Emacs crushers in console probably by M-w

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Tue, 27 Sep 2022 05:51:02 UTC

Severity: normal

Tags: moreinfo, notabug

Found in version 29.0.50

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

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Tue, 27 Sep 2022 05:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jean Louis <bugs <at> gnu.support>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 27 Sep 2022 05:51:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Emacs crushers in console probably by M-w
Date: Tue, 27 Sep 2022 08:48:13 +0300
I am running Emacs from console by using gdb, so it crashed when I used
M-w but cannot remember how exactly. I select something, I can see
selected text in blue, and I run gdb in console with gdb --args emacs -Q
-nw then Emacs receives some signal, sometimes, I caught something:

(gdb) backtrace 
#0  0x00007ffff60192b1 in pselect () at /usr/lib/libc.so.6
#1  0x00005555557db811 in really_call_select (arg=0x7fffffffca10) at thread.c:612
#2  0x00005555557dbf8f in flush_stack_call_func (arg=0x7fffffffca10, func=0x5555557db7a0 <really_call_select>)
    at /home/data1/protected/Programming/Software/emacs/src/lisp.h:4225
#3  thread_select
    (func=<optimized out>, max_fds=max_fds <at> entry=9, rfds=rfds <at> entry=0x7fffffffcb10, wfds=wfds <at> entry=0x7fffffffcb90, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7fffffffd170, sigmask=<optimized out>) at thread.c:644
#4  0x00005555557ffe0d in xg_select
    (fds_lim=9, rfds=0x7fffffffd2a0, wfds=0x7fffffffd320, efds=0x0, timeout=<optimized out>, sigmask=0x0) at xgselect.c:184
#5  0x00005555557b332b in wait_reading_process_output
    (time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=<optimized out>) at process.c:5685
#6  0x00005555555afe90 in sit_for (timeout=timeout <at> entry=0x7a, reading=reading <at> entry=true, display_option=display_option <at> entry=1)
    at dispnew.c:6238
#7  0x00005555556dd8b7 in read_char
    (commandflag=1, map=0x555555fb4c93, prev_event=0x0, used_mouse_menu=0x7fffffffda6b, end_time=0x0)
    at /home/data1/protected/Programming/Software/emacs/src/lisp.h:761
#8  0x00005555556de753 in read_key_sequence
    (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10036
#9  0x00005555556e0605 in command_loop_1 () at keyboard.c:1384
#10 0x000055555575ad17 in internal_condition_case
    (bfun=bfun <at> entry=0x5555556e0440 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556d3460 <cmd_error>)
    at eval.c:1492
#11 0x00005555556cbc56 in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1132
#12 0x000055555575ac71 in internal_catch
    (tag=tag <at> entry=0xf7e0, func=func <at> entry=0x5555556cbc30 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1215
#13 0x00005555556cbbf1 in command_loop () at keyboard.c:1110
#14 0x00005555556d2fe2 in recursive_edit_1 () at keyboard.c:719
#15 0x00005555556d3370 in Frecursive_edit () at keyboard.c:802
#16 0x00005555555a4ed2 in main (argc=4, argv=0x7fffffffe068) at emacs.c:2517




In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.17.6, Xaw3d scroll bars) of 2022-09-16 built on
 protected.rcdrun.com
Repository revision: 3c1579697ff03d3991b41ead503211cffac0998f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Parabola GNU/Linux-libre

Configured using:
 'configure --with-x-toolkit=lucid'

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
WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  font-lock-mode: t
  blink-cursor-mode: 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:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip 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
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 x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 39184 8186)
 (symbols 48 5118 2)
 (strings 32 14268 1914)
 (string-bytes 1 402527)
 (vectors 16 10388)
 (vector-slots 8 157779 11738)
 (floats 8 40 15)
 (intervals 56 255 0)
 (buffers 1000 11))

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Tue, 27 Sep 2022 06:44:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Tue, 27 Sep 2022 09:42:51 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Date: Tue, 27 Sep 2022 08:48:13 +0300
> 
> 
> I am running Emacs from console by using gdb, so it crashed when I used
> M-w but cannot remember how exactly. I select something, I can see
> selected text in blue, and I run gdb in console with gdb --args emacs -Q
> -nw then Emacs receives some signal, sometimes, I caught something:
> 
> (gdb) backtrace 
> #0  0x00007ffff60192b1 in pselect () at /usr/lib/libc.so.6
> #1  0x00005555557db811 in really_call_select (arg=0x7fffffffca10) at thread.c:612
> #2  0x00005555557dbf8f in flush_stack_call_func (arg=0x7fffffffca10, func=0x5555557db7a0 <really_call_select>)
>     at /home/data1/protected/Programming/Software/emacs/src/lisp.h:4225
> #3  thread_select
>     (func=<optimized out>, max_fds=max_fds <at> entry=9, rfds=rfds <at> entry=0x7fffffffcb10, wfds=wfds <at> entry=0x7fffffffcb90, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7fffffffd170, sigmask=<optimized out>) at thread.c:644
> #4  0x00005555557ffe0d in xg_select
>     (fds_lim=9, rfds=0x7fffffffd2a0, wfds=0x7fffffffd320, efds=0x0, timeout=<optimized out>, sigmask=0x0) at xgselect.c:184
> #5  0x00005555557b332b in wait_reading_process_output
>     (time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=<optimized out>) at process.c:5685
> #6  0x00005555555afe90 in sit_for (timeout=timeout <at> entry=0x7a, reading=reading <at> entry=true, display_option=display_option <at> entry=1)
>     at dispnew.c:6238
> #7  0x00005555556dd8b7 in read_char
>     (commandflag=1, map=0x555555fb4c93, prev_event=0x0, used_mouse_menu=0x7fffffffda6b, end_time=0x0)
>     at /home/data1/protected/Programming/Software/emacs/src/lisp.h:761

Is this a backtrace from the crash, or is this just a backtrace after
attaching GDB to a running Emacs?  It doesn't look to me as a crash.
It looks like Emacs is idle waiting for input.

Is the crash reproducible?




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 27 Sep 2022 11:47:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Tue, 27 Sep 2022 21:18:03 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Tue, 27 Sep 2022 23:18:24 +0300
* Eli Zaretskii <eliz <at> gnu.org> [2022-09-27 09:43]:
> Is this a backtrace from the crash, or is this just a backtrace after
> attaching GDB to a running Emacs?  It doesn't look to me as a crash.
> It looks like Emacs is idle waiting for input.
> 
> Is the crash reproducible?

That is backtrace after Emacs crashed. Because it is "often"
reproducible, that is why I was running Emacs under gdb.

I cannot know WHEN it will take place, that is why I was running
longer until it happened, and have sent you backtrace. From there on,
I guess you are the one with skills to find out why and what.

It happened many times. It is something related to marking the region
and pressing M-w

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Wed, 28 Sep 2022 02:34:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Wed, 28 Sep 2022 05:32:56 +0300
> Date: Tue, 27 Sep 2022 23:18:24 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 58104 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [2022-09-27 09:43]:
> > Is this a backtrace from the crash, or is this just a backtrace after
> > attaching GDB to a running Emacs?  It doesn't look to me as a crash.
> > It looks like Emacs is idle waiting for input.
> > 
> > Is the crash reproducible?
> 
> That is backtrace after Emacs crashed. Because it is "often"
> reproducible, that is why I was running Emacs under gdb.

It doesn't look like a crash, and the information about the fatal
signal was missing.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Wed, 28 Sep 2022 09:42:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Wed, 28 Sep 2022 12:09:27 +0300
* Eli Zaretskii <eliz <at> gnu.org> [2022-09-28 05:33]:
> > Date: Tue, 27 Sep 2022 23:18:24 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 58104 <at> debbugs.gnu.org
> > 
> > * Eli Zaretskii <eliz <at> gnu.org> [2022-09-27 09:43]:
> > > Is this a backtrace from the crash, or is this just a backtrace after
> > > attaching GDB to a running Emacs?  It doesn't look to me as a crash.
> > > It looks like Emacs is idle waiting for input.
> > > 
> > > Is the crash reproducible?
> > 
> > That is backtrace after Emacs crashed. Because it is "often"
> > reproducible, that is why I was running Emacs under gdb.
> 
> It doesn't look like a crash, and the information about the fatal
> signal was missing.

Emacs received SIGINT, that was it.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Wed, 28 Sep 2022 11:58:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Wed, 28 Sep 2022 14:57:11 +0300
> Date: Wed, 28 Sep 2022 12:09:27 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 58104 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [2022-09-28 05:33]:
> > > That is backtrace after Emacs crashed. Because it is "often"
> > > reproducible, that is why I was running Emacs under gdb.
> > 
> > It doesn't look like a crash, and the information about the fatal
> > signal was missing.
> 
> Emacs received SIGINT, that was it.

SIGINT cannot cause a crash in -nw sessions.  Emacs programs the
terminal to produce SIGINT when you type C-g, and when SIGINT is
delivered, Emacs converts it into a QUIT -- just like you expect when
you type C-g in Emacs.

The only way to cause Emacs to abort via SIGINT in -nw sessions is to
press C-g several times quickly enough while Emacs is busy -- this
activates the so-called "emergency exit" feature, whereby Emacs will
abort after asking you whether you really meant that.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Sat, 01 Oct 2022 03:58:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Sat, 01 Oct 2022 03:56:59 +0000
It asked me in console if I wish to dump core, save session, and restart, something like that.

SIGINT is what I have read on screen. 

Later in few days I will try to run it again, you can tell me what to put focus on.


Jean




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Sat, 01 Oct 2022 06:29:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Sat, 01 Oct 2022 09:27:41 +0300
tags 58104 notabug
close 58104
thanks

> Date: Sat, 01 Oct 2022 03:56:59 +0000
> CC: 58104 <at> debbugs.gnu.org
> From: Jean Louis <bugs <at> gnu.support>
> 
> It asked me in console if I wish to dump core, save session, and restart, something like that.
> 
> SIGINT is what I have read on screen. 

This is the emergency exit feature, not a bug.  If you don't want
Emacs to abort in this situation (e.g., if you pressed C-g by
accident, but don't intend to end the session), then answer NO to the
questions.

So I'm closing this bug.




Added tag(s) notabug. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 01 Oct 2022 06:29:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 58104 <at> debbugs.gnu.org and Jean Louis <bugs <at> gnu.support> Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 01 Oct 2022 06:29:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Wed, 05 Oct 2022 19:16:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Wed, 5 Oct 2022 21:50:01 +0300
* Eli Zaretskii <eliz <at> gnu.org> [2022-10-01 09:29]:
> tags 58104 notabug
> close 58104
> thanks
> 
> > Date: Sat, 01 Oct 2022 03:56:59 +0000
> > CC: 58104 <at> debbugs.gnu.org
> > From: Jean Louis <bugs <at> gnu.support>
> > 
> > It asked me in console if I wish to dump core, save session, and restart, something like that.
> > 
> > SIGINT is what I have read on screen. 
> 
> This is the emergency exit feature, not a bug.  If you don't want
> Emacs to abort in this situation (e.g., if you pressed C-g by
> accident, but don't intend to end the session), then answer NO to the
> questions.
> 
> So I'm closing this bug.

I never said that I have pressed C-g by accident. That is your assumption.


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Wed, 05 Oct 2022 19:26:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Wed, 05 Oct 2022 22:24:55 +0300
> Date: Wed, 5 Oct 2022 21:50:01 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 58104 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [2022-10-01 09:29]:
> > tags 58104 notabug
> > close 58104
> > thanks
> > 
> > > Date: Sat, 01 Oct 2022 03:56:59 +0000
> > > CC: 58104 <at> debbugs.gnu.org
> > > From: Jean Louis <bugs <at> gnu.support>
> > > 
> > > It asked me in console if I wish to dump core, save session, and restart, something like that.
> > > 
> > > SIGINT is what I have read on screen. 
> > 
> > This is the emergency exit feature, not a bug.  If you don't want
> > Emacs to abort in this situation (e.g., if you pressed C-g by
> > accident, but don't intend to end the session), then answer NO to the
> > questions.
> > 
> > So I'm closing this bug.
> 
> I never said that I have pressed C-g by accident. That is your assumption.

I don't understand how it matters whether you pressed C-g by accident
or not.  If you did press C-g several times, then what happened is
expected.

If you didn't press C-g at all, I don't understand how SIGINT happened
at all in this case, since C-g is the only way it can happen.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58104; Package emacs. (Wed, 05 Oct 2022 19:51:01 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58104 <at> debbugs.gnu.org
Subject: Re: bug#58104: 29.0.50; Emacs crushers in console probably by M-w
Date: Wed, 5 Oct 2022 22:43:49 +0300
* Eli Zaretskii <eliz <at> gnu.org> [2022-10-05 22:25]:
> If you didn't press C-g at all, I don't understand how SIGINT happened
> at all in this case, since C-g is the only way it can happen.

I will try to catch it again and let you know.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 03 Nov 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 166 days ago.

Previous Next


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