6.4.3. sed segmentation fault

On one occasion, I got the following very disturbing error:

/usr/local/bin/runsed: line 54: 27611 Segmentation fault sed -f $SEDSCR $x >/tmp/$y$$

Output of the corrected SGML file broke at a line for no apparent reason. Openjade complained (of course) with some errors, but processed the file. I noticed that something went wrong from the output of thumbpdf (see Section 6.4.2): thumbpdf prints the page number for each page it processes - and this time it only printed half that many. I was not able to find the reason for the segmentation fault. I guess it has to do with the exceptionally long line that sed had to process: LyX produces very long SGML lines. It does not break the lines at SGML tags and clutters them on one line for reasons unknown to me. That particular line was thus more than 3400 characters[1] long when it was output without the error. As soon as I added some innocent text that made it a little longer, it would cause the segmentation fault above. I guess this breaks some input line length limitation in sed. However, this is denied to be the case in the sed manual on the (non-)limitations on line length:

For those who want to write portable SED scripts, be aware that some implementations have been known to limit line lengths (for the pattern and hold spaces) to be no more than 4000 bytes. The POSIX.2 standard specifies that conforming SED implementations shall support at least 8192 byte line lengths. GNU SED has no built-in limit on line length; as long as SED can malloc() more (virtual) memory, it will allow lines as long as you care to feed it (or construct within it).

The only remedy if this limit does exist (as it seems to be in my case), is to shorten your text, or introduce a paragraph, admonition (see Section 4.7, Section 5.8), code or other environment (Section 5.1) that may persuade LyX to start a new SGML line in the exported SGML text.