[bug-gv] heisenbug disabling BBox

[Bernhard R. Link]

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