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/