Description of problem: Different/incorrect results with programs when print statements (with no side effects) are embedded. Version-Release number of selected component (if applicable): [mukund@jurassic ~]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) [mukund@jurassic ~]$ How reproducible: Always Steps to Reproduce: 1. Download the bcrops.c and bcrops2.c programs (which are attached). 2. Do a diff between them (to see that the differences are just the GTK+ print statements) 3. Compile them as GTK+ programs: gcc --std=c99 -O0 -Wall `pkg-config gtk+-2.0 --cflags` -o bcrops bcrops.c `pkg-config gtk+-2.0 --libs` gcc --std=c99 -O0 -Wall `pkg-config gtk+-2.0 --cflags` -o bcrops2 bcrops2.c `pkg-config gtk+-2.0 --libs` 4. Run them with the following parameters: $ ./bcrops -12.360752 390.102567 287.037454 409.095041 312.360752 9.897433 12.962546 -9.095041 0.000000 $ ./bcrops2 -12.360752 390.102567 287.037454 409.095041 312.360752 9.897433 12.962546 -9.095041 0.000000 Actual results: Only crops.c displays the green rectangle. crops2.c doesn't. bcrops.c: Result is (13, 9) - (288, 391) bcrops2.c: Result is (14, -8) - (-2147483648, -7) Expected results: Both should display green rectangles with the following output: Result is (13, 9) - (288, 391) Additional info: Setting this as urgent as this may be a bug in the C compiler.
Created attachment 144155 [details] Correct behaviour program
Created attachment 144156 [details] Program which results in faulty output
Some developers in #gtk have confirmed that both programs work fine on their distros. So this is more likely a compiler issue with the gcc in FC6.
No, it is just buggy application. Try: --- bcrops.c 2006-12-21 11:06:06.000000000 +0100 +++ bcrops.c 2006-12-21 11:31:35.000000000 +0100 @@ -199,6 +199,7 @@ gimp_transform_resize_crop (gdouble dx1 gint height, width, fixed_width; gint area; +if (ylo < 0) abort (); xlo = xint[ylo].x; xhi = xint[yhi].x; and you'll see that it accesses memory before the xint array. The difference between the version with g_printerr and without that is just in what happens to be in the memory before &xint[0].
Hi Jakub Thanks for catching it.. another developer just asked me to run it under Valgrind and it reported the invalid reads: ==7803== Invalid read of size 8 ==7803== at 0x401D01: gimp_transform_resize_crop (crops.c:203) ==7803== by 0x402682: main (crops.c:370) ==7803== Address 0x5737448 is 16 bytes before a block of size 7,120 alloc'd I logged in now to close the bug report, but you beat me to it. I should have checked this under Valgrind before reporting it. Thanks again and sorry for wasting your time!