GNU bug report logs - #40323
28.0.50; error in process filter: Invalid search bound (wrong side of point)

Previous Next

Package: emacs;

Reported by: Jacob Lagares Pozo <jlagarespo <at> iebesalu.cat>

Date: Mon, 30 Mar 2020 11:11:02 UTC

Severity: normal

Tags: moreinfo

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jacob Lagares Pozo <jlagarespo <at> iebesalu.cat>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 40323 <at> debbugs.gnu.org
Subject: bug#40323: 28.0.50; error in process filter: Invalid search bound (wrong side of point)
Date: Tue, 5 May 2020 14:01:08 +0200
[Message part 1 (text/plain, inline)]
Hello Noam,

I'm sorry for the late reply. I have been having some problems with the 
power source of my computer as of lately. Everything seems to be doing 
fine now though, so I'll get back to this.

I made a very simple program that just prints a bunch of stuff to stdout 
and stderr:

If I run it without your patches, it works surprisingly just fine (I 
noticed the original errors pop up most commonly on Slack I guess 
because it prints a lot more?), whereas if I evaluate said patches, this 
is the output of the trace buffer:

|======================================================================
1 -> (comint-output-filter #<process Shell> "stdout:
hello, world
Im gonna print some stuff
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
stderr:
AHHHH PANIC CATASTROPHIC FAILIURE!!!
The quick brown fox jumps over the lazy dog.
")(:comint-pmark nil)
| 2 -> (set-marker #<marker in no buffer> 1)(:comint-pmark nil)
| 2 <- set-marker: #<marker at 1 in *Async Shell Command*>(:comint-pmark 
(#<marker at 1 in *Async Shell Command*> . #<marker at 1 in *Async Shell 
Command*>))
| 2 -> (set-marker #<marker at 1 in *Async Shell Command*> 
191)(:comint-pmark (#<marker at 1 in *Async Shell Command*> . #<marker 
at 1 in *Async Shell Command*>))
| 2 <- set-marker: #<marker at 191 in *Async Shell 
Command*>(:comint-pmark (#<marker at 1 in *Async Shell Command*> . 
#<marker at 191 in *Async Shell Command*>))
| 2 -> (ansi-color-process-output "stdout:
hello, world
Im gonna print some stuff
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
stderr:
AHHHH PANIC CATASTROPHIC FAILIURE!!!
The quick brown fox jumps over the lazy dog.
")(:comint-pmark (#<marker at 1 in *Async Shell Command*> . #<marker at 
191 in *Async Shell Command*>))
| 2 <- ansi-color-process-output: nil(:comint-pmark (#<marker at 1 in 
*Async Shell Command*> . #<marker at 191 in *Async Shell Command*>))
| 2 -> (comint-adjust-window-point #<window 31 on *Async Shell Command*> 
#<process Shell>)(:comint-pmark (#<marker at 1 in *Async Shell Command*> 
. #<marker at 191 in *Async Shell Command*>))
| 2 <- comint-adjust-window-point: nil(:comint-pmark (#<marker at 1 in 
*Async Shell Command*> . #<marker at 191 in *Async Shell Command*>))
| 2 -> (set-marker #<marker (moves after insertion) at 191 in *Async 
Shell Command*> 191)(:comint-pmark (#<marker at 1 in *Async Shell 
Command*> . #<marker at 191 in *Async Shell Command*>))
| 2 <- set-marker: #<marker (moves after insertion) at 191 in *Async 
Shell Command*>(:comint-pmark (#<marker at 1 in *Async Shell Command*> . 
#<marker at 191 in *Async Shell Command*>))
1 <- comint-output-filter: #<marker (moves after insertion) at 191 in 
*Async Shell Command*>(:comint-pmark nil)
|

I am not sure what does this mean, perhaps it is some special character 
Slack uses for logging that messes with those markers, I don't know. 
Maybe I could try printing all of the ASCII characters sequentially and 
see what happens.

Regardless, I'm still not entirely sure what your code is doing anyway.

Thanks, Jacob

PS: I don't know if I might have accidentally sent the message halfway 
writing it; if you see anything weird in another message, that might be 
the reason why.

On 21/04/2020 04:29, Noam Postavsky wrote:
> Jacob Lagares Pozo <jlagarespo <at> iebesalu.cat> writes:
>
>> I should probably make a simple program that prints a bunch of stuff
>> and then hangs, so I can have predictable and reproducible output,
>> that might help.
> It occurs to me that you should see a "non-local exit" in the trace when
> the error triggers, and the traces just before that should hopefully
> show the swapping of marker positions occuring.
>
>> So what do you exactly mean by that the process is ending normally?
> Oh, hmm, I was still a bit confused.  I thought the (:comint-pmark nil)
> meant the marker was deleted, but actually it's just because around the
> call to comint-output-filter a different buffer is current (which makes
> the check in the tracing function fail).  Maybe one more tweak to the
> tracing function:
>
>      (defun bug-40323-get-comint-output-marker ()
>        (list :comint-pmark
>              (let ((buf (and (markerp comint-last-output-start)
>                              (marker-buffer comint-last-output-start))))
>                (when (buffer-live-p buf)
>                  (cons
>                   comint-last-output-start
>                   (process-mark (get-buffer-process buf)))))))
[Message part 2 (text/html, inline)]
[bbndlgkhocibkjda.png (image/png, inline)]

This bug report was last modified 2 years and 361 days ago.

Previous Next


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