* Hang entering summary buffer
@ 2002-12-04 0:56 David Z Maze
2002-12-04 2:35 ` Jesper Harder
0 siblings, 1 reply; 5+ messages in thread
From: David Z Maze @ 2002-12-04 0:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
I get a hang entering the summary buffer if it contains the attached
message. Using current CVS Gnus as of this message, under XEmacs on
Solaris. C-g gets me back to the group buffer with the attached
backtrace.
[-- Attachment #2: Backtrace --]
[-- Type: text/plain, Size: 4388 bytes --]
Signaling: (quit)
gnus-summary-goto-subject(3525)
(progn (subst-char-in-region start (point) ?\n ?\r) (gnus-summary-goto-subject article))
(if (and (> ... start) (search-backward "\n" start t)) (progn (subst-char-in-region start ... ?\n ?\r) (gnus-summary-goto-subject article)) (goto-char start) nil)
(prog1 (if (and ... ...) (progn ... ...) (goto-char start) nil))
(if (and (not ...) (or ... ...)) (prog1 (if ... ... ... nil)))
(when (and (not ...) (or ... ...)) (prog1 (if ... ... ... nil)))
(let ((buffer-read-only nil) (start ...) (article ...)) (goto-char start) (when (and ... ...) (prog1 ...)))
gnus-summary-hide-thread()
(if (or (not predicate) (gnus-map-articles predicate ...)) (gnus-summary-hide-thread))
(when (or (not predicate) (gnus-map-articles predicate ...)) (gnus-summary-hide-thread))
(while (not end) (when (or ... ...) (gnus-summary-hide-thread)) (setq end (not ...)))
(let ((end nil)) (while (not end) (when ... ...) (setq end ...)))
(save-excursion (goto-char (point-min)) (let (...) (while ... ... ...)))
gnus-summary-hide-all-threads(nil)
(if (and gnus-show-threads gnus-thread-hide-subtree) (gnus-summary-hide-all-threads (if ... ... nil)))
(when (and gnus-show-threads gnus-thread-hide-subtree) (gnus-summary-hide-all-threads (if ... ... nil)))
gnus-summary-maybe-hide-threads()
(if (and (zerop ...) (not no-display)) (progn (gnus-summary-catchup-and-exit nil t) (gnus-message 6 "No unread news") (when kill-buffer ...) nil) (gnus-summary-maybe-hide-threads) (when kill-buffer (gnus-kill-or-deaden-summary kill-buffer)) (gnus-summary-auto-select-subject) (if (and ... ... gnus-newsgroup-unreads gnus-auto-select-first) (progn ... ...) (gnus-summary-position-point) (gnus-configure-windows ... ...) (gnus-set-mode-line ...)) (when (get-buffer-window gnus-group-buffer t) (let ... ... ... ...)) (setq gnus-newsgroup-prepared t) (gnus-run-hooks (quote gnus-summary-prepared-hook)) t)
(cond ((not new-group) (gnus-set-global-variables) (when kill-buffer ...) (gnus-configure-windows ... ...) (gnus-set-mode-line ...) (gnus-summary-position-point) (message "") t) ((null did-select) (when ... ... ...) (let ... ...) nil) ((eq did-select ...) (and ... ... ...) (when kill-buffer ...) (if ... ... ...) (signal ... nil)) (t (gnus-set-global-variables) (setq gnus-newsgroup-active ...) (gnus-run-hooks ...) (gnus-update-format-specifications nil ... ... ...) (gnus-update-summary-mark-positions) (when gnus-use-scoring ...) (when gnus-build-sparse-threads ...) (if gnus-show-threads ... ...) (unless no-display ...) (when gnus-use-trees ... ...) (when ... ...) (gnus-run-hooks ...) (if ... ... ... ... ... ... ... ... ... t)))
(let* ((new-group ...) (quit-config ...) (did-select ...)) (cond (... ... ... ... ... ... ... t) (... ... ... nil) (... ... ... ... ...) (t ... ... ... ... ... ... ... ... ... ... ... ... ...)))
gnus-summary-read-group-1("nnml:mail.lists.debian.bugs.dist" 5 t nil nil nil)
(or (gnus-summary-read-group-1 group show-all no-article kill-buffer no-display select-articles) (setq show-all nil select-articles nil))
(let ((gnus-auto-select-next nil)) (or (gnus-summary-read-group-1 group show-all no-article kill-buffer no-display select-articles) (setq show-all nil select-articles nil)))
(setq result (let (...) (or ... ...)))
(null (setq result (let ... ...)))
(and group (null (setq result ...)) (eq gnus-auto-select-next (quote quietly)))
(while (and group (null ...) (eq gnus-auto-select-next ...)) (set-buffer gnus-group-buffer) (when backward (gnus-group-prev-unread-group 2)) (if (not ...) (setq group ...) (setq group nil)))
(let (result) (while (and group ... ...) (set-buffer gnus-group-buffer) (when backward ...) (if ... ... ...)) result)
gnus-summary-read-group("nnml:mail.lists.debian.bugs.dist" 5 t nil nil nil nil)
(let ((no-display ...) (group ...) number active marked entry) (when (eq all 0) (setq all nil)) (unless group (error "No group on current line")) (setq marked (gnus-info-marks ...)) (setq number (cond ... ... ...)) (gnus-summary-read-group group (or all ...) no-article nil no-display nil select-articles))
gnus-group-read-group(5 t)
gnus-group-select-group(5)
(if (gnus-group-topic-p) (let (...) (gnus-topic-fold all) (gnus-dribble-touch)) (gnus-group-select-group all))
gnus-topic-select-group(5)
call-interactively(gnus-topic-select-group)
[-- Attachment #3: 3525 --]
[-- Type: message/rfc822, Size: 3931 bytes --]
From: Robert Nagy <thuglife@linuxforum.hu>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#171555: ITP: kernel-patch-sensors Hardware health monitoring tool (kernel patch)\r
.\r
This package contains two kernel patches. For 2.4.19 and 2.4.20.
Date: Tue, 03 Dec 2002 10:11:21 +0100
Message-ID: <20021203091121.DB6559FEC5@linuxforum.hu>
Package: wnpp
Version: unavailable; reported 2002-12-03
Severity: wishlist
* Package name : kernel-patch-sensors
Version : 2.6.5
Upstream Author : The Lm_sensors Group <sensors@stimpy.netroedge.com>
* URL : http://www2.lm-sensors.nu/~lm78/
* License : GPL
Description : Lm-sensors is a hardware health monitoring package for Linux (kernel patch)
(Include the long description here.)
I've created the patches on my own for 2.4.19 and 2.4.20 from the
lm-sensors-source package.
This patch allow you patch you kernel with lm_sensors.
This package Depends on kernel-patch-i2c. So if I don't post another ITP
about that. If it is needed please mail me immediatly.
You can downolad them from:
deb http://ers.linuxforum.hu/debian/ ./
deb-src http://ers.linuxforum.hu/debian/ ./
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux thuglife.homelinux.org 2.4.19 #4 Fri Nov 29 21:45:51 CET 2002 i686
Locale: LANG=en_US, LC_CTYPE=en_US
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
[-- Attachment #4: Type: text/plain, Size: 168 bytes --]
--
David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Hang entering summary buffer
2002-12-04 0:56 Hang entering summary buffer David Z Maze
@ 2002-12-04 2:35 ` Jesper Harder
2002-12-04 2:46 ` Katsumi Yamaoka
0 siblings, 1 reply; 5+ messages in thread
From: Jesper Harder @ 2002-12-04 2:35 UTC (permalink / raw)
David Z Maze <dmaze@MIT.EDU> writes:
> I get a hang entering the summary buffer if it contains the attached
> message.
It happens because the Subject line is badly broken, it contains an
embedded CR/LF. You should probably file a bug report against the
program,
X-Mailer: reportbug 2.9,
that generates this kind of junk.
But of course Gnus should be resilient. We probably need some test for
embedded linebreaks somewhere in rfc2047-decode-*, but we should be a
bit careful since those functions can affect the performance of summary
buffer generation noticeably.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Hang entering summary buffer
2002-12-04 2:35 ` Jesper Harder
@ 2002-12-04 2:46 ` Katsumi Yamaoka
2002-12-04 3:57 ` Jesper Harder
0 siblings, 1 reply; 5+ messages in thread
From: Katsumi Yamaoka @ 2002-12-04 2:46 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
>>>>> In <m38yz6zf1w.fsf@defun.localdomain>
>>>>> Jesper Harder <harder@ifa.au.dk> wrote:
> It happens because the Subject line is badly broken, it contains an
> embedded CR/LF.
AFAIK, the MIME header encoding doesn't express newlines in
principle, so such encoded words are evil. The following patch
may also be evil, but I think it or similar solution is needed
to Gnus. How about it?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 571 bytes --]
--- rfc2047.el~ 2002-09-14 03:37:43 +0000
+++ rfc2047.el 2002-12-04 02:39:53 +0000
@@ -520,6 +520,13 @@
(prog1
(match-string 0)
(delete-region (match-beginning 0) (match-end 0)))))
+ ;; Remove newlines or excessive whitespace between decoded words.
+ (save-restriction
+ (narrow-to-region e (point))
+ (goto-char e)
+ (while (re-search-forward "[\t\n\r ]+" nil t)
+ (replace-match " "))
+ (goto-char (point-max)))
(when (and (mm-multibyte-p)
mail-parse-charset
(not (eq mail-parse-charset 'us-ascii))
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Hang entering summary buffer
2002-12-04 2:46 ` Katsumi Yamaoka
@ 2002-12-04 3:57 ` Jesper Harder
2002-12-04 6:44 ` Katsumi Yamaoka
0 siblings, 1 reply; 5+ messages in thread
From: Jesper Harder @ 2002-12-04 3:57 UTC (permalink / raw)
Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>>>>> In <m38yz6zf1w.fsf@defun.localdomain>
>>>>>> Jesper Harder <harder@ifa.au.dk> wrote:
>
>> It happens because the Subject line is badly broken, it contains an
>> embedded CR/LF.
>
> AFAIK, the MIME header encoding doesn't express newlines in
> principle, so such encoded words are evil.
Yes. RFC 2047 actually mentions that you should beware of this
possibility:
Only printable and white space character data should be encoded using
this scheme. However, since these encoding schemes allow the
encoding of arbitrary octet values, mail readers that implement this
decoding should also ensure that display of the decoded data on the
recipient's terminal will not cause unwanted side-effects.
> The following patch may also be evil, but I think it or similar
> solution is needed to Gnus. How about it?
It's slighly evil :-) I don't think we should remove excessive
whitespace here (other than \n and \r).
I know that a lot of clients have broken RFC 2047 en/decoder that often
introduce spurious whitespace. But if we remove it we're breaking the
standard. If people want to clean it up, they should include
`gnus-simplify-whitespace' in `gnus-simplify-subject-functions' instead.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Hang entering summary buffer
2002-12-04 3:57 ` Jesper Harder
@ 2002-12-04 6:44 ` Katsumi Yamaoka
0 siblings, 0 replies; 5+ messages in thread
From: Katsumi Yamaoka @ 2002-12-04 6:44 UTC (permalink / raw)
>>>>> In <m3r8cyxwp6.fsf@defun.localdomain>
>>>>> Jesper Harder <harder@ifa.au.dk> wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> The following patch may also be evil, but I think it or similar
>> solution is needed to Gnus. How about it?
> It's slighly evil :-) I don't think we should remove excessive
> whitespace here (other than \n and \r).
Yes, indeed. I've changed the function rfc2047-decode-region in order
to remove only CRLFs.
> I know that a lot of clients have broken RFC 2047 en/decoder that often
> introduce spurious whitespace. But if we remove it we're breaking the
> standard. If people want to clean it up, they should include
> `gnus-simplify-whitespace' in `gnus-simplify-subject-functions' instead.
That reminds me that I should use it. Thanks.
--
Katsumi Yamaoka <yamaoka@jpl.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-12-04 6:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-04 0:56 Hang entering summary buffer David Z Maze
2002-12-04 2:35 ` Jesper Harder
2002-12-04 2:46 ` Katsumi Yamaoka
2002-12-04 3:57 ` Jesper Harder
2002-12-04 6:44 ` Katsumi Yamaoka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).