there appears to be no check on the length of mon_line ;P (no that's not what the '1' in strncat does - that function has no total length limitation ;) so either mon_line itself is overflowed. or printf overflows at not seeing a terminating '0' to the overflowed string ;) windows.h: char mon_line[256]; /Downloads/linpac-0.28/src# less windows.cc if (ev.type == EV_NONE) { if (listpid >= 0) { char buf[512]; int rc = read(list, buf, 512); if (rc > 0) { int i; for (i=0; i < rc; i++) { if (buf[i] == '\r'...
according to the manpage on pipe() pipe's buffer size can simply be set to PIPE_BUF (mon_line=PIPE_BUF;) (#include<limits.h> as there appear to be 2 diffent ones one for posix (512) and one for gnu (4096) and then, at least with with O_DIRECT it'll never fail on that bit ;)</limits.h> Writes of greater than PIPE_BUF bytes (see pipe(7)) will be split into multiple packets. The constant PIPE_BUF is defined in <limits.h>.</limits.h> * If a read(2) specifies a buffer size that is smaller than the next...
works fine after changing mon_line to 512 in src/windows.h ... could be a bit overkill... the way it is done highly depends on pre-existing termios settings etc anyway. (as in if it even is one line of text at a time that gets read() in the first place ) think that whole part could well do with a rewrite... for one thing... instead of pipe dup2 exec ( axlisten )
axlisten seems to write() it actually line by line. (not just one write() with a lot of \n's in it ;) but how many bytes you get from a read() on a redirected terminal depends on the termios settings of that terminal. and is not per-se one line at a time... (especially not since it is also in non blocking mode ;) anyway the problem is in that strncat(bla,mon_line,1) bit which doesn't check the length of mon_line at all. just that it appends one byte at a time to it. ;) also the newlines, carriage...
axlisten seems to write() it actually line by line. (not just one write() with a lot of \n's in it ;) but how many bytes you get from a read() on a redirected terminal depends on the termios settings of that terminal. and is not per-se one line at a time... anyway the problem is in that strncat(bla,mon_line,1) bit which doesn't check the length of mon_line at all. just that it appends one byte at a time to it. ;)
works fine after changing mon_line to 512 in src/windows.h ... could be a bit overkill... the way it is done highly depends on pre-existing termios settings etc anyway. (as in if it even is one line of text at a time that gets read() in the first place ) think that whole part could well do with a rewrite... for one thing... instead of pipe dup2 exec ( axlisten ) (there is popen for that? , also it seems to dup both STDOUT_FILENO and STDERR_FILENO to the same filedescriptor ;) or actually just STDERR...
with axlisten broken on the box i tried to update that axlibrary stuff on at least it no longer crashes ;) no monitor tho. not that a monitor is needed per-se on a multi user multi tasking os... if they want axlisten they can just run one in another terminal.