I'm not sure where to begin with describing this problem, but here's my situation. I'm using gnuscreen, but I can't tell if this has anything to do with my problem. (The text is actually going over the network through ssh to another box.)

I've written a program that produces a LOT of text output to stdout. Like a megabyte/sec. Sometimes, the program will just freeze. If I press ctrl-z and then type "fg", it continues where it left off.

I connected a debugger. Here's the stack trace:

(gdb) where
#0 0x00007f342e1a72e0 in __write_nocancel () from /lib/libc.so.6
#1 0x00007f342e1520ea in _IO_new_file_write (f=0x7f342e437780, data=0x7f342edfd083, n=187) at fileops.c:1268
#2 0x00007f342e151d4a in new_do_write (fp=0x7f342e437780,
data=0x7f342edfd000 "\033[7m25\033[m 4 5 \033[7m 6 \033[m\033[7m 6 \033[m 1 5 5 4 5 \033[7m 6 \033[m 5 5 5 5 5 5 5 3 \033[7m 6 \033[m 5 3 5 \033[7m 6 \033[m\033[7m 6 \033[m\033[7m 6 \033[m 4 5 5 5 5 4 4 \033[7m 6 \033[m 5 \033[7m 6 \033[m 171\n 172\n 171"..., to_do=187) at fileops.c:522
#3 0x00007f342e152085 in _IO_new_do_write (fp=0x1,
data=0x7f342edfd083 "\033[m 4 5 5 5 5 4 4 \033[7m 6 \033[m 5 \033[7m 6 \033[m 171\n 172\n 171\n 171\n4 4 3 171\n 173\nm22\033[m \033[7m23\033[m \033[7m24\033[m \033[7m25\033[m \033[7m26\033[m \033[7m27\033[m \033[7m28\033[m \033[7m29\033[m \033[7m30\033[m \033[7m31\033[m \033[7m3"..., to_do=187) at fileops.c:494
#4 0x00007f342e151ea9 in _IO_new_file_xsputn (f=0x7f342e437780, data=0x40420b, n=1) at fileops.c:1350
#5 0x00007f342e125359 in _IO_vfprintf_internal (s=0x7f342e437780, format=<value optimized out>, ap=0x7fffb255b2b0) at vfprintf.c:1610
#6 0x00007f342e1c7e9d in ___printf_chk (flag=1, format=0x0) at printf_chk.c:37
#7 0x0000000000401274 in common_table ()
#8 0x0000000000402be8 in fixup_all_overlaps ()
#9 0x0000000000402d5e in main ()

So basically, it's getting stuck in something called by printf.

Does anyone have any ideas as to how to investigate why this freeze might be happening?

Thanks.

If screen is left in 'copy' mode, it's buffer will fill and writes to stdout will block. Is this possibly the problem?

--- rod.

Good though, but no. I was watching the program work (which involves a lot of text updating on the screen), when suddenly, it froze. I could switch screens (in screen), but only suspending and restarting the program would unfreeze it.

maybe you are writing two fast
try slowing it down just to test
i am new to linux so i dont completely know what anybody is talking about
but in dos if you write to fast i have had the computer freeze

Is it possible to not use screen, at least for the purposes of diagnosing the problem? Is screen open in multi-user mode? If so, how many displays are active? Is it possible to eliminate the network from the equation? Sustained MB/sec throughput is pretty high, especially if multiple users are watching. Your stack trace shows what appear to be many, many embedded escape sequences, all of which require interpretation by screen, and the accordant terminal manipulation. As much as I was prepared to dismiss smeezekitty's reply as specious, I wonder whether there may be some validity to it.
--- rod.

try writing to the screen as fast as possable on a 386
be ready to press CTL+ALT+DEL