|Summary:||There appears to be some kind of 'buffer overrun' problem with gnome-terminals and xterms when executing lots of printf() statements|
|Product:||[Retired] Red Hat Linux||Reporter:||Need Real Name <todds>|
|Component:||XFree86||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-05-12 13:16:52 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2000-11-16 21:02:24 UTC
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 17:20:30 UTC
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 23:24:43 UTC
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 20:19:49 UTC
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 possible? Thanks, Todd
Comment 4 Need Real Name 2001-02-08 02:02:05 UTC
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 21:22:32 UTC
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 23:27:57 UTC
Created attachment 9962 [details] application to reproduce the kernel printf() problem
Comment 7 Need Real Name 2001-02-13 23:28:01 UTC
Created attachment 9963 [details] resend of application to reproduce the kernel printf() problem
Comment 8 Need Real Name 2001-02-14 00:11:35 UTC
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 13:28:31 UTC
I'm defering this to my todo list so it gets looked into sooner.
Comment 10 Mike A. Harris 2001-05-29 00:12:13 UTC
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.