Somewhere there is a ugly little bug hiding I fail to properly locate. The symptom is gv not using the BoundingBox of a specific eps file. (Some eps file with which it works here is in the original report found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627471 ).
The faulty behaviour appears and vanishes under very strange situations: The original reporter had it depending on giving a relative filename or a absolute one (I could never reproduce that). Things I have seen that make it go away: - setting LC_CTYPE or LC_ALL (even to C) makes it disappear, only with none of those variables set it shows up here. - running in valgrind makes it disappear - gdb does not seem to have any effect - compiling some things without optimisation can make it go away, but in a way that I think this mostly is related to positions within the binary changing. - adding some asm("nop") at the right locations can make it disappear, on some locations it has no effect, on other locations one need multiple nops. - changing the link order (i.e. doing the link manually and switch the order of .o files at the command line) can make the difference between bug or no bug, though I guess that is also mostly about changing of offsets and/or alignment within the code. - the smallest difference I yet come up with is the following: + compile everything "-O2 -g" then the bug is there. + compile ps.c to .s by replacing "-o ps.o" with "-S -o ps.s" + add '.string "123457"' after '.string "PageBoundingBox:"' + rm ps.o ; as -o ps.o -c ps.s + rm gv ; make + bug is still there + move the '.string "1234567"' up to be between '.string "PageMedia:"' and the label directly before '.string "PageBoundingBox:' + rm ps.o ; as -o ps.o -c ps.s + rm gv ; make + bug is gone objdump -s of the two gv fles generated this way show as only differences: 4 bytes changed in .text and the "123457\0" switching it's position with "PageBoundingBox\0" in .rodata objdump -d says that those 4 differences in the code are 4 times the 2. argument for dsc_strncmp (two times for "PageBoundingBox:" and two times for "BoundingBox:" (gcc is storing those two strings as one)) Looking at dsc_strncmp I see nothing that could explain why a difference like that could have effects like that. As it does this funny malloc/free every time (no idea why it does that as it could just to strncasecmp(s1, s2, n-1)) that might mean that there simply is some harvoc going on with the memory mangement code. Optimising that function to not do the temporary copy makes the bug disappear, but that might simply be a code moves around effect.... Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org