Crash when creating a linkage diagrams of extra-long sentences about link-grammar HOT 6 CLOSED

I finally implemented another solution, in the lines of the existing check of row overrun:
Just put an error message into the diagram string and return.

It does that when the sentence itself doesn't fit into a diagram line. This usually doesn't cause a crash, unless it is to fit into the last row. However, a sentence slightly longer than that would cause end of diagram lines to be written into the start of the next diagram line, which is not a good thing. So when this condition is detected, the following is put into the diagram string: "The diagram is too long.".

BTW, another bug happens with extra-long sentences: they cause a buffer overrun in libedit when it reads the history file which contains extra-long sentence. This happens with libedit-3.1-9.

from link-grammar.

Ugh. I suggest that you report this bug to the libedit folks. You might
even want to provide a patch, if you have time :-)

Buffer over-runs can be used to get root: if some SUID program is using
libedit, and you feed it that long line, or tamper with the history buffer,
then you will get root on that machine. So technically, this could even be
a CVE

On Fri, Feb 20, 2015 at 5:41 PM, Amir Plivatsky [email protected]
wrote:

I finally implemented another solution, in the lines of the existing check
of row overrun:
Just put an error message into the diagram string and return.

It does that when the sentence itself doesn't fit into a diagram line.
This usually doesn't cause a crash, unless it is to fit into the last row.
However, a sentence slightly longer than that would cause end of diagram
lines to be written into the start of the next diagram line, which is not a
good thing. So when this condition is detected, the following is put into
the diagram string: "The diagram is too long.".

BTW, another bug happens with extra-long sentences: they cause a buffer
overrun in libedit when it reads the history file which contains
extra-long sentence. This happens with libedit-3.1-9.

—
Reply to this email directly or view it on GitHub
#101 (comment)
.

from link-grammar.

I found the problem in libedit. It is due to an off-by-one comparison in a condition that allocates a bigger buffer, and can happen with any line length. It exists in the current dev. CVS, and hence I sent a bug report, with a fix.
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=49683
(Unfortunately I didn't know they don't allow line folding on display...)

from link-grammar.

fwiw we use libedit because it was compatible with the BSD license. But since that's not an issue any more, we could use readline. It might be .. ? better? Support for utf8 in libedit has been spotty, readline I assume is better for this.

from link-grammar.

Regretfully readline is under GPL, and not LGPL (see http://en.wikipedia.org/wiki/GNU_Readline).
So using it would put the link-parser program under GPL. This doesn't matter for the LG library itself, but I think it is best not to put anything in the project under GPL.

BTW, the maintainer of libedit handled my bug report and promptly fixed the problem (first by a bogus fix, but then he changed it to a good fix).

I made some searches but have not found yet another line-editing library that also supports Unicode.

from link-grammar.

well, the problem is that it takes years for the fixes to bubble up to the distros.

For example: the utf8 support was there for, .. I dunno 4-5 years already, but it needed a compile-time flag to be turned on, (it was off by default) and the distro's forgot to turn it on (all of them: ubuntu, redhat, debian). I told them about this, so they fixed it .. at first, incorrectly, and so another 6-9 months lost. For example, if I remember, its missing in ubuntu 14.04 LTS and will remain missing for years, until the next LTS.

from link-grammar.