Bug 2411 - quicksearch_history content partially written to stdout
Summary: quicksearch_history content partially written to stdout
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Other (show other bugs)
Version: 3.7.9
Hardware: PC FreeBSD
: P3 normal
Assignee: users
URL:
: 3417 4088 4182 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-25 14:06 UTC by Fabian Keil
Modified: 2021-02-16 19:48 UTC (History)
5 users (show)

See Also:


Attachments
Patch proposal not to display unmatched characters at lexer level (295 bytes, patch)
2021-02-08 13:12 UTC, wwp
no flags Details | Diff

Description Fabian Keil 2011-04-25 14:06:18 UTC
If a .claws-mail/quicksearch_history line contains spaces
it gets written to stdout with the spaces removed.

The output is buffered so unless --debug is used it only
shows up when claws-mail exits.

With:
fk@r500 ~ $cat .claws-mail/quicksearch_history
aaa
bbb bbb bbb
ccc
ddd
eeee eee
ff

I get:
fk@r500 ~ $claws-mail
bbbbbbbbbeeeeeeefk@r500 ~ $

Setting a break point at fwrite(), I get:
(gdb) where
#0  0x00000008073e38f4 in fwrite () from /lib/libc.so.7
#1  0x0000000000504fc4 in matcher_parserlex () at matcher_parser_lex.l:131
#2  0x00000000005072cc in matcher_parserparse () at matcher_parser_parse.c:2133
#3  0x0000000000506d99 in matcher_parser_get_cond (str=0x80866af50 "bbb bbb bbb", is_fast=0x0) at matcher_parser_parse.y:228
#4  0x000000000065d2bf in quicksearch_set_search_strings (quicksearch=0x8084c3040) at quicksearch.c:1517
#5  0x00000000004ed894 in main (argc=1, argv=0x7fffffffd8b0) at main.c:1472

The behavior can be stopped with:

--- src/matcher_parser_lex.c
+++ src/matcher_parser_lex.c
@@ -1035,7 +1035,6 @@ YY_RULE_SETUP
 case 17:
 YY_RULE_SETUP
 #line 131 "matcher_parser_lex.l"
-ECHO;
        YY_BREAK
 #line 1041 "matcher_parser_lex.c"
                        case YY_STATE_EOF(INITIAL):

but this isn't a real fix as the file is generated.

I haven't been able to track down where the ECHO is coming
from or if it's supposed to be reached at all, though.
Comment 1 Paul 2015-06-26 11:47:14 UTC
*** Bug 3417 has been marked as a duplicate of this bug. ***
Comment 2 Ricardo Mones 2015-06-26 13:14:15 UTC
That "ECHO;" line is not present on my generated matcher_parser_lex.c, so it's some problem with your lex/flex which may be generating the default rule for unmatched text (probably because of the empty user code section).

Some ideas to try:

a) If you build from git, in src/Makefile.am add "AM_LFLAGS = -s" above 
   AM_YFLAGS line. You have to run toplevel autogen.sh then build.

b) Remove last %% from matcher_parser_lex.l and try building.

c) Instead removing last %%, add /* */ below it and try building.

If nothing of the above works, which lex/flex version are you using?
Comment 3 Fabian Keil 2015-06-26 13:31:14 UTC
The FreeBSD/ElectroBSD port currently uses the generated file that is bundled in the upstream source tarball:

$ tar xOf /usr/ports/distfiles/claws-mail-3.11.1.tar.xz claws-mail-3.11.1/src/matcher_parser_lex.c | cat -n | grep -3 "ECHO;"
  1043	case 17:
  1044	YY_RULE_SETUP
  1045	#line 131 "matcher_parser_lex.l"
  1046	ECHO;
  1047		YY_BREAK
  1048	#line 1049 "matcher_parser_lex.c"
  1049				case YY_STATE_EOF(INITIAL):

Thanks for the suggestions, I'll give them a try this weekend.
Comment 4 Ricardo Mones 2015-06-26 13:55:39 UTC
Sorry, seems I was looking at the wrong place: I also have that "ECHO;" line in my generated .c file.

I've also checked that a) works, though you probably have to either start from scratch or remove your current .c file.

Anyway, the result is somewhat I don't like much:

#line 131 "matcher_parser_lex.l"
YY_FATAL_ERROR( "flex scanner jammed" );

A ECHO is harmless, but I suspect a fatal error is not what we want to replace it.
Comment 5 Paul 2018-09-25 11:30:02 UTC
*** Bug 4088 has been marked as a duplicate of this bug. ***
Comment 6 Paul 2019-03-21 11:49:21 UTC
*** Bug 4182 has been marked as a duplicate of this bug. ***
Comment 7 Sergei Trofimovich 2021-02-06 08:11:32 UTC
Noticed stdout dumps as well. I noticed that generated lexer has a place to inject own ECHO handler with ECHO definition:

/* Copy whatever the last rule matched to the standard output. */
#ifndef ECHO
/* This used to be an fputs(), but since the string might contain NUL's,
 * we now use fwrite().
 */
#define ECHO do { if (fwrite( yytext, (size_t) yyleng, 1, yyout )) {} } while (0)
#endif

Would it be reasonable to set it to no-op by claws-mail itself?
Or perhaps extend a lexer to explicitly handle unexpected input?
Comment 8 wwp 2021-02-08 13:12:33 UTC
Created attachment 2174 [details]
Patch proposal not to display unmatched characters at lexer level
Comment 9 wwp 2021-02-15 11:00:41 UTC
Anyone to try/comment the proposed patch?
Comment 10 Fabian Keil 2021-02-15 17:15:28 UTC
The patch looks good to me and seems to work as advertised.

Thanks.
Comment 11 wwp 2021-02-15 19:07:07 UTC
Thanks, Fabian.

Note You need to log in before you can comment on or make changes to this bug.