GNU bug report logs -
#486
pgg-gpg.el - pgg-gpg-process-region timing problem
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 486 in the body.
You can then email your comments to 486 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#486
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"ken manheimer" <ken.manheimer <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
i am not sure how to proceed with this problem. as demonstrated by
the pggprob.el script, i consistently get encryption and decryption
problems without the contrived delay in my pgg-gpg-process-region
patch. (the problem does not happen if i just do a regular
pgg-decrypt - i think the crucial thing is that a symmetric passphrase
is being passed into pgg-gpg-process-region.)
i have tried everything i could think of to exclude local quirks from
the problem, including starting emacs with '--no-site-file -q' and
eliminating everything from my ~/.gnupg/gpg.conf file. i have
reproduced the problem (and workaround) consistently in kubuntu 8.04
emacs-snapshot package and a recent CVS HEAD checkout. in fact, i
have incidentally reinstalled my kubuntu 8.04 OS recently, on both my
main 2.0 Ghz T43 thinkpad and on a 750 Mhz a20p thinkpad. the problem
continues consistently on the t43 but does *not* occur on the a20p,
which is not contrary to the sensitivities of a timing problem.
i have also tried thien-thi nguyen's alternative approaches, but
neither worked for me, hanging in different places.
i am pretty sure this is a real problem, and something that warrants
attention. i realize that the difficulty in repeating the problem
elsewhere increases the challenge in addressing it, and am open to
cooperating with people to try things, if that would help. the
consistent effectiveness of my workaround should help provide clues
about the nature of the problem, at least.
any suggestions?
--
ken
http://myriadicity.net
On Sun, Jun 22, 2008 at 1:37 PM, ken manheimer <ken.manheimer <at> gmail.com> wrote:
> allout encryption, which depends on pgg.el &c, has been failing due to
> a weird timing problem i've narrowed down to the
> pgg-gpg-process-region function. this is in emacs 23.0.60 built from
> a CVS HEAD checkout of an hour or so ago, and some earlier 23.0.60
> versions. i've reproduced the problem using emacs -q and regularly
> launched emacs, etc.
>
> the problem is that pgg-gpg-process-region often returns a nil status
> despite successful decryption, unless a delay (eg, (sleep-for .3) is
> inserted between process start and later interaction with the process.
> with the delay, the status is something like 207 or 208, while
> without it the status is nil - yet, on examination the content is
> sucessfully decrypted.
>
> the size of the delay needs to be increased when the machine is
> heavily loaded, and can be reduced (on my thinkpad t43 2 GHz laptop,
> 3Gb ram, running kubuntu 8.0.4 +) to no lower than (sleep-for .2).
> rarely, the proper status is returned without the delay, depending on
> the machine load and other things i can't identify. considering the
> real-time sensitivity of the problem, your mileage will almost
> certainly vary!
>
> i originally thought the problem might be in gpg, but now figure it
> resides either in the emacs process mechanism, pgg's use of that, or
> somewhere in the combination of emacs and pgg.
>
> i've created a simple .el script, pggprob.el, with minimal code and
> data to produce the problem, and a patch, pggprob-patch.txt, with a
> single-line modification to pgg-gpg-process-region to work around the
> problem. both are attached. since the workaround is merely a timing
> delay, it's clearly not a fix! i'm hoping this is enough to enable
> others to reproduce the problem, and investigate...
> --
> ken
> http://myriadicity.net
>
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
> `bt full' and `xbacktrace'.
> If you would like to further debug the crash, please read the file
> /home/klm/src/emacs-HEAD/etc/DEBUG for instructions.
>
> In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
> of 2008-06-22 on twist
> Windowing system distributor `The X.Org Foundation', version 11.0.10400090
> Important settings:
> value of $LC_ALL: nil
> value of $LC_COLLATE: nil
> value of $LC_CTYPE: nil
> value of $LC_MESSAGES: nil
> value of $LC_MONETARY: nil
> value of $LC_NUMERIC: nil
> value of $LC_TIME: nil
> value of $LANG: en_US.UTF-8
> value of $XMODIFIERS: nil
> locale-coding-system: utf-8-unix
> default-enable-multibyte-characters: t
>
> Major mode: Emacs-Lisp
>
> Minor modes in effect:
> tooltip-mode: t
> tool-bar-mode: t
> mouse-wheel-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> global-auto-composition-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
>
> Recent input:
> C-x C-f <M-backspace> <M-backspace> <M-backspace> l
> i b / e m a <tab> a l l <tab> s c r <tab> p g g p <tab>
> <return> M-x e v a l - c u r <tab> <return> M-. C-g
> M-> C-x C-e M-x e m a c s <M-backspace> r e p o r t
> - e m <tab> <return>
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Source file `/home/klm/src/emacs-HEAD/lisp/pgg-gpg.el' newer than
> byte-compiled file
> Quit
> Mark set
> nil
>
--
ken
http://myriadicity.net
[pggprob.el (application/octet-stream, attachment)]
[pgg-patch.txt (text/plain, attachment)]
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#486
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #12 received at 486 <at> emacsbugs.donarmstrong.com (full text, mbox):
> i am not sure how to proceed with this problem. as demonstrated by
> the pggprob.el script, i consistently get encryption and decryption
> problems without the contrived delay in my pgg-gpg-process-region
> patch. (the problem does not happen if i just do a regular
> pgg-decrypt - i think the crucial thing is that a symmetric passphrase
> is being passed into pgg-gpg-process-region.)
I haven't been able to reproduce this problem, so let me make sure I
understand your recipe correctly.
First, I create a buffer with the following contents
(setq passphrase "a"
verifier "-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.6 (GNU/Linux)
jA0EAwMCo72fNGB1rNxgySv+rxdkPv46nVxQ5fg4yT78ldgVcDseD7Mre4Fhjifn
VTA1/PdmetVfFb9+
=MXF6
-----END PGP MESSAGE-----"
count 0)
(defun decrypt (passphrase text)
(with-current-buffer (get-buffer-create "*pgg-test*")
(erase-buffer)
(insert text)
(pgg-decrypt nil nil passphrase)))
Then, I eval the buffer with M-x eval-buffer.
Finally, I do
M-: (decrypt passphrase verifier) RET
This consistently gives me the message `208' in the echo area. I don't
see a nil result, but that's what you see, correct?
bug archived.
Request was from
Debbugs Internal Request <don <at> donarmstrong.com>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Sun, 31 Aug 2008 14:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 15 years and 146 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.