Red Hat Bugzilla – Bug 20980
There appears to be some kind of 'buffer overrun' problem with gnome-terminals and xterms when executing lots of printf() statements
Last modified: 2005-10-31 17:00:50 EST
There appears to be some kind of 'buffer overrun' problem with
gnome-terminals and xterms when executing lots of printf() statements.
The client/server network software application I'm developing
transfers data over the network and then when all of the data is
successfully received, it prints out each column field on a
separate stdout print line. The problem is that the last two and a
half lines of a nine line ASCII configuration file never get
For example, the seventh line prints out as:
(INT16) fid: 0 43
(INT16) fid: 1 44
(INT16) fid: 2 45
instead of say the sixth line which printed out o.k. which looked like:
(INT16) fid: 0 36
(INT16) fid: 1 37
(INT16) fid: 2 38
(INT16) fid: 3 39
(INT16) fid: 4 40
(INT16) fid: 5 41
(INT32) fid: 6 0
(INT16) fid: 7 42
When I ran the exact same client and server applications from one of
the Linux 'real' ttys instead of the gnome-terminal or xterm 'psuedo'
ttys, all nine lines of the configuration file printed fine! I'm not
sure how to debug this one any further as it appears to be some kind
of kernel buffering/buffer overrun problem. Of course when I ran the
client under gdb, the problem didn't occur but everytime I run it
without gdb it stops printing out the data at the exact same point and
is very repeatable.
The eighth and ninth configuration lines never get even partially
If you can, please provide a minimal amount of code that triggers this,
and any specific test conditions so that the problem can be replicated
easily for testing.
I'll try to untangle the current client/server source code into a stand
alone module that I can actually email to you that doesn't contain
any proprietary code, but I'm buried right now and probably won't get to
it until after Thanksgiving/next week. My guess is you could just write
a while loop with a counter and printf statement in it.
I have developed a compact stand alone software application that reproduces the
problem. I will email the source code and Makefile as a 'tar.gz' file to
'email@example.com'. Mike, can you please compile the application and run it
on your machine and verify that you are able to reproduce the problem as soon as
Has any progress been made on this bug report??? It is really interfering with
my development efforts.
I have also tried version 2.2.18 non-SMP kernel and the problem still occurs.
I must have lost the file you sent me for testing - which is why bugzilla
has a file attachment feature. We do not accpet bug reports via mail for
this very reason - that when the mail comes in, and when the bug gets looked
at are not necessarily the same time. As a result, the mail gets buried/lost
and there is nothing to tie the email to the bug report. Attach a new copy
to the bug report with the "Create a new attachment" link above, and I'll
be glad to look into the problem. You might also want to give the latest
XFree release from rawhide a shot to see if it fixes the problem.
Created attachment 9962 [details]
application to reproduce the kernel printf() problem
Created attachment 9963 [details]
resend of application to reproduce the kernel printf() problem
Please use the 9963 attachment as I was having web problems/submit problems when
I submitted the 9962 attachment. You can delete the 9962 attachment as I
couldn't figure out how to.
For some reason the attachment I submitted shows up as 'showattachment.cgi'
instead of 'printf_problem.tar.gz' when you go to download it. You can still
extract the files that make up the application that reproduces the problem by
running the following command:
'zcat showattachment.cgi | tar xvf -'
This command will create a directory called 'printf_problem'.
Simply 'cd printf_problem' and run 'make'.
Use ./main to run the program.
You should see something like the following:
Before fcntl() - line #0490
Before fcntl() - line #0491
Before fcntl() - line #0492
Before fcntl() - line #0493
Before fcntl() - line #0494
Before fcntl() - line #0495
Before fcntl() - line #0496
Before fcntl() - line #0497
Before fcntl() - line #0498
Before fcntl() - line #0499
After fcntl( O_NONBLOCK ) - line #0000
After fcntl( O_NONBLOCK ) - line #0001
After fcntl( O_NONBLOCK ) - line #0002
After fcntl( O_NONBLOCK ) - line #0003
After fcntl( O_NONBLOCK ) - line #0004
After fcntl( O_NONBLOCK ) - line #0005
After fcntl( O_NONBLOCK ) - line #0006
After fcntl( O_NONBLOCK ) - line #0007
After fcntl( O_NONBLOCK ) - line #0008
After fcntl( O_NONBLOCK ) - line #0009
After fcntl( O_NON
This is where lines 10-500 are dropped!
I'm defering this to my todo list so it gets looked into sooner.
I have tried to reproduce this on several installations using xterm,
gnome-terminal, and konsole. In every case the program works as one would
expect it to. I will be making an errata release of 3.3.6 for RHL 6.2 soon,
which you can try: ftp://people.redhat.com/mharris/testing/6.2
If that doesn't work for you, then it is either something wrong with your
local installation, or is a legitimate bug that I can't reproduce. At any rate
it is not present in Red Hat Linux 7.0 or 7.1, so my recommendation is to upgrade
to Red Hat Linux 7.1 if the problem persists.