RE: cygwin 1.5.20-1 problem writing to stdout

["Dave Korn" <dave dot korn at artimi dot com>]

On 06 July 2006 16:31, Nellis, Kenneth wrote:

> A program, which Iâve had for years and which has worked on many
> different Unix variants, stopped working when I upgraded to cygwin
> 1.5.20-1. When I back-installed 1.5.19-4, it resumed working.
> Actually, the program functioned fine, but output to stdout was
> stifled. I was able to reduce the program to the following few lines,
> which exhibit the problem:
> 
> =========== xyz.c ================
> #include <stdio.h>
> 
> static char b[4001];
> static char *whoami;
> 
> int main (int argc, char *argv[])
> {
>    puts ("hello");
>    return 0;
> }
> ==================================
> 
> (The unreferenced variables are indeed referenced in the larger
> program and are required for this smaller program to exhibit the
> problem.)

  Wow, we borked hello world!

> The problem is unrelated to terminal I/O because output is stifled
> even when stdout is redirected to a file.
> 
> Removing either the b or whoami variables or reducing 4001 to 4000
> allows the program to work again.
> 
> I'd like to hear if anyone else can reproduce this problem.

  Confirmed.  Annoyingly enough, it doesn't happen under debug.

Hmm: good version (size of array b 4000)

00403000 b .bss
00403000 B ___cygwin_crt0_bp
00403000 B __bss_start__
00403010 b .bss
00403010 b _b
00403fb0 b _whoami
00403fc0 b .bss
00403fc0 b .bss
00403fc0 b .bss
00403fc0 B __fmode
00403fc4 B _environ
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403ff0 B __bss_end__
00404000 i .idata$2
00404000 I __head_cygwin1_dll
00404014 i .idata$2
00404014 I __head_libkernel32_a

Bad version: (size of array b 4001)

00403000 b .bss
00403000 B ___cygwin_crt0_bp
00403000 B __bss_start__
00403010 b .bss
00403010 b _b
00403fc0 b _whoami
00403fd0 b .bss
00403fd0 b .bss
00403fd0 b .bss
00403fd0 B __fmode
00403fd4 B _environ
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00404000 i .idata$2
00404000 B __bss_end__
00404000 I __head_cygwin1_dll

Good version again: (size of array b 4018)

00403000 b .bss
00403000 B ___cygwin_crt0_bp
00403000 B __bss_start__
00403010 b .bss
00403010 b _c
00403fd0 b _iamwhatiam
00403fe0 b .bss
00403fe0 b .bss
00403fe0 b .bss
00403fe0 B __fmode
00403fe4 B _environ
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00403ff0 b .bss
00404010 B __bss_end__
00405000 i .idata$2
00405000 I __head_cygwin1_dll

  I wonder if something in the crt code is trying to 4096 align the __bss_end__ variable, getting it wrong because it lands exactly on the start of the .idata section, and trashing some of the imports?  Make the array any smaller, the bss end will be at 0x00403xxx and won't round up into 0x00404xxx, make it another 16 bytes bigger and the idata section will be forced up to 0x00405xxx.  I suspect the bss-zeroing code.  Haven't got time to look at it right now though.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/