I just ran into the same problem and found that this happens due to column_maxline.diff which allocates a buffer that is too small because it implicitly assumes sizeof(wchar_t) == 2 which is wrong.
The attached patch should fix this issue.
From 4fbb900f04fd737d6422b613ada7034249fec5fc Mon Sep 17 00:00:00 2001 From: Julian Brost <jul...@0x4a42.net> Date: Sun, 1 Sep 2019 21:48:27 +0200 Subject: [PATCH] column_maxline.diff: use correct size for buffer By using a hard-coded shift left by one, the patch implicitly assumed that sizeof(wchar_t) == 2, but this is not always the case and the buffer may be too small. This commit fixes this by using sizeof(wchar_t) to calculate the correct size for the buffer. This fixes #893497 --- debian/patches/column_maxline.diff | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/patches/column_maxline.diff b/debian/patches/column_maxline.diff index c35e7f4..eab84c4 100644 --- a/debian/patches/column_maxline.diff +++ b/debian/patches/column_maxline.diff @@ -18,7 +18,7 @@ Author: Michael Meskes <mes...@debian.org> - wchar_t *p, buf[MAXLINELEN]; + wchar_t *p, *buf; + -+ buf = malloc(MAXLINELEN<<1); ++ buf = malloc(MAXLINELEN * sizeof(wchar_t)); + if (!buf) + err(1, (char *)NULL); -- 2.20.1
