GNU bug report logs - #14970
Assertion failure deleting frames

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Sun, 28 Jul 2013 00:24:02 UTC

Severity: normal

Found in version 24.3.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 14970 in the body.
You can then email your comments to 14970 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#14970; Package emacs. (Sun, 28 Jul 2013 00:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Juanma Barranquero <lekktu <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 28 Jul 2013 00:24:05 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: crash deleting frames
Date: Sun, 28 Jul 2013 02:22:51 +0200
Package: emacs
Version: 24.3.50

Context: I'm trying new desktop code to force frames onscreen. To test
it, I have a function that creates a fair number of frames (around
15/20) either partially or totally offscreen.

Once the new desktop code moves them onscreen, I usually close them
all via another interactive test function. But if I try instead to
close them by clicking on each window's Close button, sooner or later
(after closing 10/15 frames, usually) Emacs crashes.

In previous crashes it didn't generate a backtrace, nor did Windows
offer to attach a debugger to the crashed program. Also, running under
gdb I couldn't reproduce the bug. This is the first time I've been
offered to attach gdb.

Whatever the reason, something fishy is happening with delete-frame,

#0  0x76c7321a in KERNELBASE!DeleteAce () from
C:\Windows\syswow64\KernelBase.dll
#1  0x011ea460 in emacs_abort () at w32fns.c:8030
#2  0x010db418 in terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:369
#3  0x0115059d in die (msg=0x148470a "WINDOWP (a)", file=0x1484694
"lisp.h", line=798) at alloc.c:6558
#4  0x0114682c in XWINDOW (a=54749210) at lisp.h:798
#5  0x010129af in delete_frame (frame=93052933, force=54749234) at frame.c:1161
#6  0x01013496 in Fdelete_frame (frame=93052933, force=54749234) at frame.c:1451
#7  0x0116dadc in Ffuncall (nargs=3, args=0x88efe4) at eval.c:2819
#8  0x011ae49d in exec_byte_code (bytestr=19842041, vector=19842061,
maxdepth=16, args_template=54749210, nargs=0, args=0x0) at
bytecode.c:905
#9  0x0116e65c in funcall_lambda (fun=19842013, nargs=1,
arg_vector=0x12ec40d) at eval.c:3050
#10 0x0116dcf2 in Ffuncall (nargs=2, args=0x88f320) at eval.c:2865
#11 0x01167794 in Fcall_interactively (function=54934394,
record_flag=54749210, keys=90185989) at callint.c:839
#12 0x0116db0b in Ffuncall (nargs=4, args=0x88f54c) at eval.c:2823
#13 0x011ae49d in exec_byte_code (bytestr=19717001, vector=19717021,
maxdepth=52, args_template=4100, nargs=4, args=0x88f860) at
bytecode.c:905
#14 0x0116e298 in funcall_lambda (fun=19716981, nargs=4,
arg_vector=0x88f850) at eval.c:2984
#15 0x0116dcf2 in Ffuncall (nargs=5, args=0x88f84c) at eval.c:2865
#16 0x0116d661 in call4 (fn=54795106, arg1=54934394, arg2=54749210,
arg3=90185989, arg4=54749234) at eval.c:2664
#17 0x010e256f in read_char (commandflag=1, map=91059750,
prev_event=54749210, used_mouse_menu=0x88fac3, end_time=0x0) at
keyboard.c:2923
#18 0x010ee02f in read_key_sequence (keybuf=0x88fbe0, bufsize=30,
prompt=54749210, dont_downcase_last=false,
can_return_switch_frame=true,
    fix_current_buffer=true) at keyboard.c:9056
#19 0x010df234 in command_loop_1 () at keyboard.c:1434
#20 0x0116a91f in internal_condition_case (bfun=0x10deebd
<command_loop_1>, handlers=54803674, hfun=0x10de744 <cmd_error>) at
eval.c:1302
#21 0x010deb72 in command_loop_2 (ignore=54749210) at keyboard.c:1161
#22 0x0116a239 in internal_catch (tag=54793554, func=0x10deb4e
<command_loop_2>, arg=54749210) at eval.c:1076
#23 0x010deb2a in command_loop () at keyboard.c:1140
#24 0x010de2e1 in recursive_edit_1 () at keyboard.c:779
#25 0x010de49d in Frecursive_edit () at keyboard.c:843
#26 0x010dc76b in main (argc=5, argv=0xc22d98) at emacs.c:1566

Lisp Backtrace:
"delete-frame" (0x88efe8)
"handle-delete-frame" (0x88f324)
"call-interactively" (0x88f550)
"command-execute" (0x88f850)
(gdb)




Changed bug title to 'Assertion failure deleting frames' from 'crash deleting frames' Request was from Juanma Barranquero <lekktu <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 28 Jul 2013 00:27:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 01:09:02 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 03:08:08 +0200
A crash, while closing a maximized frame.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7104.0x1f30]
0x011e08b1 in w32_wnd_proc (hwnd=0x6c088c, msg=269, wParam=0,
lParam=0) at w32fns.c:3216
3216              w = XWINDOW (FRAME_SELECTED_WINDOW (f));
(gdb) bt
#0  0x011e08b1 in w32_wnd_proc (hwnd=0x6c088c, msg=269, wParam=0,
lParam=0) at w32fns.c:3216
#1  0x762162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
#2  0x006c088c in ?? ()
#3  0x0000010d in ?? ()
#4  0x00000000 in ?? ()

Lisp Backtrace:
"delete-frame" (0x88efe8)
"handle-delete-frame" (0x88f324)
"call-interactively" (0x88f550)
"command-execute" (0x88f850)
(gdb) bt full
#0  0x011e08b1 in w32_wnd_proc (hwnd=0x6c088c, msg=269, wParam=0,
lParam=0) at w32fns.c:3216
        form = {
          dwStyle = 1,
          ptCurrentPos = {
            x = 8,
            y = 45
          },
          rcArea = {
            left = 8,
            top = 45,
            right = 1872,
            bottom = 540
          }
        }
        context = 0
        w = 0x6e4bfd68
        f = 0x0
        dpyinfo = 0x1523900
        wmsg = {
          msg = {
            hwnd = 0xf70828,
            message = 1981903226,
            wParam = 735304265,
            lParam = 1981903158,
            time = 16189480,
            pt = {
              x = 7080076,
              y = 1981903226
            }
          },
          dwModifiers = 16205752,
          rect = {
            left = 16205752,
            top = 0,
            right = 70,
            bottom = 1850473688
          }
        }
        windows_translate = 1850474000
        key = 1
#1  0x762162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
No symbol table info available.
#2  0x006c088c in ?? ()
No symbol table info available.
#3  0x0000010d in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 08:41:03 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 10:39:54 +0200
> 3216              w = XWINDOW (FRAME_SELECTED_WINDOW (f));

My crystal ball tells me that Eli will check whether f is a live frame
in between the following two statements of w32fns.c

	  f = x_window_to_frame (dpyinfo, hwnd);
	  w = XWINDOW (FRAME_SELECTED_WINDOW (f));

which should considerably reduce the danger that the frame has been
recycled when accessing FRAME_SELECTED_WINDOW.  I'm not sure whether
it's worth the effort having FRAME_SELECTED_WINDOW check that its
argument is a live frame.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 15:26:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 18:25:08 +0300
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 28 Jul 2013 02:22:51 +0200
> 
> Package: emacs
> Version: 24.3.50
> 
> Context: I'm trying new desktop code to force frames onscreen. To test
> it, I have a function that creates a fair number of frames (around
> 15/20) either partially or totally offscreen.
> 
> Once the new desktop code moves them onscreen, I usually close them
> all via another interactive test function. But if I try instead to
> close them by clicking on each window's Close button, sooner or later
> (after closing 10/15 frames, usually) Emacs crashes.
> 
> In previous crashes it didn't generate a backtrace, nor did Windows
> offer to attach a debugger to the crashed program. Also, running under
> gdb I couldn't reproduce the bug. This is the first time I've been
> offered to attach gdb.
> 
> Whatever the reason, something fishy is happening with delete-frame,

Does revision 113576 fix this?  If not, please try to provide a
reproducing recipe, even if it is not 100% reliable.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 15:29:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 18:28:25 +0300
> Date: Sun, 28 Jul 2013 10:39:54 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 14970 <at> debbugs.gnu.org
> 
>  > 3216              w = XWINDOW (FRAME_SELECTED_WINDOW (f));
> 
> My crystal ball tells me that Eli will check whether f is a live frame
> in between the following two statements of w32fns.c
> 
> 	  f = x_window_to_frame (dpyinfo, hwnd);
> 	  w = XWINDOW (FRAME_SELECTED_WINDOW (f));

The Force is strong with you.

Yes, I did something similar, although not exactly (you cannot just
use FRAME_LIVE_P here, because it will crash in the same way).

> which should considerably reduce the danger that the frame has been
> recycled when accessing FRAME_SELECTED_WINDOW.

Actually, I think it's recycled between the code that sent
WM_IME_STARTCOMPOSITION to the window and this code (which runs in a
different thread).

> I'm not sure whether it's worth the effort having
> FRAME_SELECTED_WINDOW check that its argument is a live frame.

No, of course not.  We already test the value returned by
x_window_to_frame almost everywhere, so this place should not be
different.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 17:05:01 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 19:04:08 +0200
On Sun, Jul 28, 2013 at 5:25 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Does revision 113576 fix this?

Hard to say, but I just deleted 40+ frames and didn't trigger the bug,
so hopefully yes. Close the bug and I'll re-open it if the bug
reappears.

> If not, please try to provide a
> reproducing recipe, even if it is not 100% reliable.

The only recipe I had: enable desktop-save-mode, create 20+ frames,
save, restore Emacs again, delete all the frames as fast as possible
by clicking on the Close buttons. And I don't think the desktop saving
& restoring is really relevant, but that's what I was doing everytime
the bug happened.




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sun, 28 Jul 2013 17:29:01 GMT) Full text and rfc822 format available.

Notification sent to Juanma Barranquero <lekktu <at> gmail.com>:
bug acknowledged by developer. (Sun, 28 Jul 2013 17:29:03 GMT) Full text and rfc822 format available.

Message #27 received at 14970-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14970-done <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 20:28:21 +0300
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 28 Jul 2013 19:04:08 +0200
> Cc: 14970 <at> debbugs.gnu.org
> 
> On Sun, Jul 28, 2013 at 5:25 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Does revision 113576 fix this?
> 
> Hard to say, but I just deleted 40+ frames and didn't trigger the bug,
> so hopefully yes. Close the bug and I'll re-open it if the bug
> reappears.

Done.

> > If not, please try to provide a
> > reproducing recipe, even if it is not 100% reliable.
> 
> The only recipe I had: enable desktop-save-mode, create 20+ frames,
> save, restore Emacs again, delete all the frames as fast as possible
> by clicking on the Close buttons. And I don't think the desktop saving
> & restoring is really relevant, but that's what I was doing everytime
> the bug happened.

Did you create the frames manually, or do you have some Lisp to
sweeten the pill?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 17:36:02 GMT) Full text and rfc822 format available.

Message #30 received at 14970-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14970-done <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 19:34:23 +0200
On Sun, Jul 28, 2013 at 7:28 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Did you create the frames manually, or do you have some Lisp to
> sweeten the pill?

I was using this. Dimensions are harcoded to make frames be totally or
partially offscren in my 1920x1040 workarea.

If you create the frames and then save the frame config with desktop
and restore with the current default, those frames that are totally
offscreen should be moved onscreen. Once that has finished, you can
start clicking Close buttons happily.

(defvar test-frame-alist-list  ;; 1920 x 1040
  '(
    ((name . "top full (400 -3000)")      (left .   400) (top + -3000))
    ((name . "top part (500 -200)")       (left .   500) (top +  -200)) ;ok
    ((name . "bot full (400 4000)")       (left .   400) (top .  4000))
    ((name . "bot part (500 900)")        (left .   500) (top .   900)) ;ok
    ((name . "left full (-3000 300)")     (left + -3000) (top .   300))
    ((name . "left part (-400 300)")      (left +  -400) (top .   300)) ;ok
    ((name . "right full (4000 200)")     (left .  4000) (top .   200))
    ((name . "right part (1800 300)")     (left .  1800) (top .   300)) ;ok
    ((name . "upleft full (-2000 -2000)") (left + -2000) (top + -2000))
    ((name . "upleft part (-100 -100)")   (left +  -100) (top +  -100)) ;ok
    ((name . "dnleft full (-2000 3000)")  (left + -2000) (top .  3000))
    ((name . "dnleft part (-300 800)")    (left +  -300) (top .   800)) ;ok
    ((name . "upright full (3000 -2000)") (left .  3000) (top + -2000))
    ((name . "upright part (1700 -200)")  (left .  1700) (top +  -200)) ;ok
    ((name . "dnright full (3000 3000)")  (left .  3000) (top .  3000))
    ((name . "dnright part (1600 900)")   (left .  1600) (top .   900)) ;ok
    ((name . "top full width")  (left . 100) (top + -1000) (width . 400))
    ((name . "top full height") (left . 100) (top + -6000)
  (height . 300))
    ((name . "top full full")   (left . 100) (top + -6000) (width .
400) (height . 300))
    ((name . "top part width")  (left . 100) (top + -300)  (width . 400))
    ((name . "top part height") (left . 200) (top + -3900)
  (height . 300))
    ((name . "top part full")   (left . 300) (top + -4200) (width .
400) (height . 300))
    ((name . "left full width")  (left + -4000) (top . 200) (width . 400))
    ((name . "left full height") (left + -4000) (top . 300)
   (height . 300))
    ((name . "left full full")   (left + -4000) (top . 400) (width .
400) (height . 300))
    ((name . "left part width")  (left + -3000) (top . 200) (width . 400))
    ((name . "left part height") (left +  -300) (top . 300)
   (height . 300))
    ((name . "left part full")   (left + -3200) (top . 400) (width .
400) (height . 300))
    ((name . "bot full width")  (left . 100) (top . 2000) (width . 400))
    ((name . "bot full height") (left . 200) (top . 3000)
 (height . 300))
    ((name . "bot full full")   (left . 300) (top . 4000) (width .
400) (height . 300))
    ((name . "bot part width")  (left . 100) (top . 700) (width . 400))
    ((name . "bot part height") (left . 200) (top . 800)
(height . 300))
    ((name . "bot part full")   (left . 300) (top . 900) (width . 400)
(height . 300))
    ((name . "right full width")  (left . 3000) (top . 200) (width . 400))
    ((name . "right full height") (left . 3000) (top . 300)
   (height . 300))
    ((name . "right full full")   (left . 3000) (top . 400) (width .
400) (height . 300))
    ((name . "right part width")  (left . 1600) (top . 200) (width . 400))
    ((name . "right part height") (left . 1700) (top . 300)
   (height . 300))
    ((name . "right part full")   (left . 1800) (top . 400) (width .
400) (height . 300))
    ((name . "upleft full width")  (left + -3000) (top + -1000) (width . 400))
    ((name . "upleft full height") (left + -3000) (top + -6000)
       (height . 300))
    ((name . "upleft full full")   (left + -3000) (top + -6000) (width
. 400) (height . 300))
    ((name . "upleft part width")  (left + -3000) (top + -300)  (width . 400))
    ((name . "upleft part height") (left + -500) (top + -3900)
      (height . 300))
    ((name . "upleft part full")   (left + -3200) (top + -4200) (width
. 400) (height . 300))
    ))

(defun make-all ()
  (interactive)
  (dolist (frame-cfg test-frame-alist-list)
   (modify-frame-parameters (make-frame) frame-cfg)))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Sun, 28 Jul 2013 17:38:01 GMT) Full text and rfc822 format available.

Message #33 received at 14970-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14970-done <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Sun, 28 Jul 2013 19:37:05 +0200
On Sun, Jul 28, 2013 at 7:34 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> If you create the frames and then save the frame config with desktop
> and restore with the current default, those frames that are totally
> offscreen should be moved onscreen.

What I meant (but didn't really say clearly ;-) is that if you want to
make *all* these frames visible, you should set
`desktop-restore-forces-onscreen' to `all'.

   J




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Mon, 29 Jul 2013 07:56:04 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Mon, 29 Jul 2013 09:54:58 +0200
> ... (you cannot just
> use FRAME_LIVE_P here, because it will crash in the same way).

How does it crash?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Mon, 29 Jul 2013 15:30:05 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Mon, 29 Jul 2013 18:29:20 +0300
> Date: Mon, 29 Jul 2013 09:54:58 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 14970 <at> debbugs.gnu.org
> 
>  > ... (you cannot just
>  > use FRAME_LIVE_P here, because it will crash in the same way).
> 
> How does it crash?

The original crash was a SIGSEGV because f was a null pointer, and
FRAME_SELECTED_WINDOW dereferenced it.  But FRAME_LIVE_P also
dereferences its argument, so it would have crashed with the same
SIGSEGV.

I guess you are thinking about a frame pointer computed from a Lisp
frame object, in which case the pointer can never be null.  But this
is not that case: here we get the frame pointer from a call to
x_window_to_frame, which returns a null pointer to signal that it
failed to find an Emacs frame that corresponds to a Windows window.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14970; Package emacs. (Mon, 29 Jul 2013 17:04:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 14970 <at> debbugs.gnu.org
Subject: Re: bug#14970: crash deleting frames
Date: Mon, 29 Jul 2013 19:03:40 +0200
> The original crash was a SIGSEGV because f was a null pointer, and
> FRAME_SELECTED_WINDOW dereferenced it.  But FRAME_LIVE_P also
> dereferences its argument, so it would have crashed with the same
> SIGSEGV.

Indeed.  I was confusing FRAME_LIVE_P and Fframe_live_p.  Thanks for the
clarification.

martin




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

This bug report was last modified 10 years and 265 days ago.

Previous Next


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