Re: [BUG] SIGSEGV under certain circumstances

[Bart Schaefer <schaefer@brasslantern.com>]

On Mar 5,  6:52pm, Peter Stephenson wrote:
}
} It needs at least to be able to do trivial matching,
} character for character, or it becomes unusable.

Point taken, though arguably it's *already* unusable if it crashes.

Let's go back to the history angle ... from Yen's original message:

} Chinese characters map to:
} 
} e7aa81 e784b6 e5a5bd e683b3 e4bda0
} 
} in utf-8 (15 bytes, 3 bytes for each character). However, in
} ~/.zsh_history, the saved content is: (I reformatted it for easier
} comparision with the correct version)
} 
} e7aa81 e783a4b6 e5a5bd e683a3b3 e4bd8380

Adding brackets to show metafied bytes:

e7aa81 e7[83a4]b6 e5a5bd e6[83a3]b3 e4bd[8380]

That is the same string that is passed to cfp_matcher_pats() according to
the backtrace.  So history is reading/writing correctly, it appears.

However, note that it's not the first byte of the three in any of these
examples that is metafied, and if we look at compmatch.c:pattern_match()
we find this:

	/*
	 * Now the line character.
	 */
#ifdef MULTIBYTE_SUPPORT
	len = mb_metacharlenconv_r(s, &c, &lstate);
#else
	/* We have the character itself. */
	if (*s == Meta) {
	    c = STOUC(s[1]) ^ 32;
	    len = 2;
	} else {
	    c = STOUC(*s);
	    len = 1;
	}
#endif

This will fail in this case, I would think?  We have to unmetafy first,
possibly several bytes ahead, and THEN attempt multibyte conversion;
not do either one or the other?

So we're likely to get a false hit on pattern_match(), and in fact the
bad dereference is of *mp in the branch where pattern_match() succeeds.

[Somebody will have to explain to me why (mp += cl) makes sense, as that
seems to be using a byte count to increment a (Cmatcher*), but it's done
in several places.]

Am I going astray here?