Re: Commit not in git release branch
On Wed, Jan 25, 2023 at 11:07:56AM +0100, Hilmar Preuße wrote: > Am 24.01.2023 um 17:45 teilte Gavin Smith mit: > > On Tue, Jan 24, 2023 at 01:29:07PM +0100, Hilmar Preuße wrote: > > Hello, > > > > I just noticed that the commit > > > > > > commit edff3e5615e6263e9be5a35c0b68799f860eb886 > > > Author: Gavin Smith > > > Date: Fri Dec 2 22:45:41 2022 + > > > > > > * info/session.c (info_beginning_of_line): Avoid freezing > > > at beginning of a file when 'nodeline' is set to 'pointers' (the > > > default). Report from Justin Anthony LaPolla > > > . > > > > > > ..is in the master branch, but missing in the release branch and hence > > > missing in the tar ball. Is there a specific reason, why it was not > > > included, i.e. should we not use it? > > > > There is no reason why it should not be used. I just had not noted it > > as important enough to include on the release branch. If there is ever > > another release on this branch I will be happy to include it. > > > OK, thanks. I've activated the patch in the Debian package. I've added the patch to the release/7.0 branch so if/when another release happens on this branch it will be included.
Further info bug fixed
On Mon, Dec 12, 2022 at 06:47:44PM +, Gavin Smith wrote: > On Mon, Dec 12, 2022 at 01:31:39PM +0100, Hilmar Preuße wrote: > > Hello, > > > > another one for you. The issue is reproducible with latest git checkout. > > I could only test on amd64, where the error message looks differently. > > > > hille@sid-amd64:~$ /usr/bin/info groff > /dev/null > > realloc(): invalid next size > > Aborted (core dumped) > > Apologies for the further crash. I believe I have fixed it in commit > 9a83ffc3d. I have also added the change to the release branch, and I > think that we should make a bug-test release fairly soon with this fix > in it (say, within a month). I still didn't get it right. This change stopped the crash but it could lead to missing text in nodes. The "Manipulating Hyphenation" node in the groff manual only had 222 lines displayed, but it should have had 323 lines. So I've made a further change (at bottom of mail). Looks like there may be a Texinfo 7.0.3 after all. diff --git a/ChangeLog b/ChangeLog index 16fd9a7d71..398c277e80 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2023-02-08 Gavin Smith + + Stop text disappearing in Info nodes with encoding conversion + + * info/util.c (text_buffer_iconv): Update text buffer length + after error so that we do not write over the same output again. + 2023-02-08 Gavin Smith Unify @multitable block line arg ending diff --git a/info/util.c b/info/util.c index 46af4ce385..bf02e36d13 100644 --- a/info/util.c +++ b/info/util.c @@ -357,6 +357,8 @@ text_buffer_iconv (struct text_buffer *buf, iconv_t iconv_state, iconv_ret = iconv (iconv_state, inbuf, inbytesleft, , _bytes_left); + text_buffer_off (buf) = outptr - text_buffer_base (buf); + if (iconv_ret != (size_t) -1) break; /* success */ @@ -366,7 +368,6 @@ text_buffer_iconv (struct text_buffer *buf, iconv_t iconv_state, else break; /* let calling code deal with it */ } - text_buffer_off (buf) = outptr - text_buffer_base (buf); return iconv_ret; }
Re: info may stress-test the terminal emulator
Hi Gavin, > There's no way for me to reproduce this. Neither can I. The next time it occurs, I hope I'll think at launching gdb immediately. Thanks for listening anyways. Bruno
Re: info may stress-test the terminal emulator
On Wed, Feb 08, 2023 at 01:46:57PM +0100, Bruno Haible wrote: > Hi, > > This is a bug report about the 'info' program (GNU texinfo 6.8). > > In a terminal emulator, I ran 'info m4', searched for m4_provide_if, then > attempted to abort this search by pressing some of the characters ESC, Enter, > Ctrl-Q, repeatedly. (I can't remember which character sequence exactly.) > At this point 'info' began to spew several BEL characters per second, which > the terminal emulator turned into popups on the screen. This caused the > terminal emulator to hang, losing the state of all the open tabs. There's no way for me to reproduce this. I have an m4 Info manual installed but the search for m4_provide_if terminates within a fraction of a second so I cannot try aborting the search by pressing different keys. Without a way to reproduce the error then it's very hard to guess what the problem might be. However, I did find a bug in the current version that the Top node of the m4 manual is not displayed properly. (Tested with Texinfo 7.0.2.) I suspect it may be related to a character encoding conversion from iso-8859-1 to utf-8. I'll investigate soon. This would be very annoying as the two previous bug fix releases both were to fix major bugs with character encoding conversion in the info program.
Intermittent t/60macro.t failure
Tested with git commit 0fb51499dd.
TEXINFO_XS=require perl -w t/60macro.t
often produces a test failure in the 'macro_in_def_delimiters' test.
It does not happen every time so I suspect a memory error.
TEXINFO_XS=require perl -w t/60macro.t macro_in_def_delimiters
on its own seems to be ok so it may be an earlier test that caused the
problem.
It seems to be related to sourcemarks:
$ diff t/results/macro/macro_in_def_delimiters.pl*
414,421d413
< 'source_marks' => [
< {
< 'counter' => 4,
< 'position' => 1,
< 'sourcemark_type' => 'macro_expansion',
< 'status' => 'end'
< }
< ],
I ran
alias VAL='valgrind --log-file=val.log'
TEXINFO_XS=require VAL perl -w t/60macro.t macro_in_misc_commands
and in val.log there is:
==226968== Conditional jump or move depends on uninitialised value(s)
==226968==at 0x82DCAC8: relocate_source_marks (source_marks.c:208)
==226968==by 0x82BA281: isolate_last_space_internal (parser.c:829)
==226968==by 0x82BA591: isolate_last_space (parser.c:921)
==226968==by 0x82CBEA1: end_line_misc_line (end_line.c:1357)
==226968==by 0x82CEAEC: end_line (end_line.c:2304)
==226968==by 0x82BFCA5: process_remaining_on_line (parser.c:2218)
==226968==by 0x82C052D: parse_texi (parser.c:2348)
==226968==by 0x82B1BB9: parse_piece (api.c:246)
==226968==by 0x82AF2D1: XS_Texinfo__Parser_parse_piece (Parsetexi.c:241)
==226968==by 0x2119D7: Perl_pp_entersub (in /usr/bin/perl)
==226968==by 0x208135: Perl_runops_standard (in /usr/bin/perl)
==226968==by 0x17B8DB: perl_run (in /usr/bin/perl)
I haven't investigated further but it's likely that fixing these
valgrind errors would stop the test failures.
Re: info may stress-test the terminal emulator
On Feb 08 2023, Bruno Haible wrote: > Andreas Schwab wrote: >> > Is there a way to fix/improve this erratic behaviour of the 'info' program, >> > please? >> >> Are you sure it's not the terminal emulator erratically sending an >> endless stream of characters to the inferior? The info program normally >> emits a BEL when it receives a character input it doesn't recognize. > > That's a theoretically possible cause, indeed. Normally the terminal emulator > sends an endless stream of characters only if > - some heavy object is lying on the keyboard, or > - some key is stuck in depressed position. - some bug causes an endless loop. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: info may stress-test the terminal emulator
Andreas Schwab wrote: > > Is there a way to fix/improve this erratic behaviour of the 'info' program, > > please? > > Are you sure it's not the terminal emulator erratically sending an > endless stream of characters to the inferior? The info program normally > emits a BEL when it receives a character input it doesn't recognize. That's a theoretically possible cause, indeed. Normally the terminal emulator sends an endless stream of characters only if - some heavy object is lying on the keyboard, or - some key is stuck in depressed position. Both wasn't the case here. So, I would still think that some of the 'terminal_ring_bell ();' invocations in info/session.c was being executed too often. But since I didn't attach gdb to 'info' at that moment, I don't know where. Bruno
Re: info may stress-test the terminal emulator
On Feb 08 2023, Bruno Haible wrote: > Is there a way to fix/improve this erratic behaviour of the 'info' program, > please? Are you sure it's not the terminal emulator erratically sending an endless stream of characters to the inferior? The info program normally emits a BEL when it receives a character input it doesn't recognize. But note that ESC does abort search. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
info may stress-test the terminal emulator
Hi, This is a bug report about the 'info' program (GNU texinfo 6.8). In a terminal emulator, I ran 'info m4', searched for m4_provide_if, then attempted to abort this search by pressing some of the characters ESC, Enter, Ctrl-Q, repeatedly. (I can't remember which character sequence exactly.) At this point 'info' began to spew several BEL characters per second, which the terminal emulator turned into popups on the screen. This caused the terminal emulator to hang, losing the state of all the open tabs. While it is certainly a bug in the terminal emulator when it hangs [1], it is a fact that this terminal emulator was running flawlessly for over two months and only the 'info' session brought it to its knees. I have the suspicion that the 'info' program was feeding an endless sequence of BEL characters to the terminal, thereby putting too much stress on it. Is there a way to fix/improve this erratic behaviour of the 'info' program, please? Bruno [1] https://bugs.kde.org/show_bug.cgi?id=465469
