Bug 20980 - There appears to be some kind of 'buffer overrun' problem with gnome-terminals and xterms when executing lots of printf() statements
There appears to be some kind of 'buffer overrun' problem with gnome-terminal...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.2
i386 Linux
high Severity high
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-16 16:02 EST by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-12 09:16:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
application to reproduce the kernel printf() problem (811 bytes, application/octet-stream)
2001-02-13 18:27 EST, Need Real Name
no flags Details
resend of application to reproduce the kernel printf() problem (811 bytes, application/octet-stream)
2001-02-13 18:28 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2000-11-16 16:02:24 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 
printed out!

For example, the seventh line prints out as:
	(INT16)		fid: 0 	43 
	(INT16)		fid: 1 	44 
	(INT16)		fid: 2 	45 
	(I

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.

Thanks,

Todd

The eighth and ninth configuration lines never get even partially
printed out.
Comment 1 Mike A. Harris 2000-11-20 12:20:30 EST
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.
Comment 2 Need Real Name 2000-11-20 18:24:43 EST
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.
Comment 3 Need Real Name 2001-01-26 15:19:49 EST
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
'mharris@redhat.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
possible?

Thanks,

Todd
Comment 4 Need Real Name 2001-02-07 21:02:05 EST
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.
Comment 5 Mike A. Harris 2001-02-13 16:22:32 EST
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.
Comment 6 Need Real Name 2001-02-13 18:27:57 EST
Created attachment 9962 [details]
application to reproduce the kernel printf() problem
Comment 7 Need Real Name 2001-02-13 18:28:01 EST
Created attachment 9963 [details]
resend of application to reproduce the kernel printf() problem
Comment 8 Need Real Name 2001-02-13 19:11:35 EST
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!
Comment 9 Mike A. Harris 2001-03-31 08:28:31 EST
I'm defering this to my todo list so it gets looked into sooner.
Comment 10 Mike A. Harris 2001-05-28 20:12:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.