Re: failure due to compiler? (Ronald F. Guilmette)
22 Jul 1996 10:53:46 -0400

          From comp.compilers

Related articles
[21 earlier articles]
Re: failure due to compiler? (1996-07-20)
Re: failure due to compiler? LEEW@FS.MICROLOGIC.COM (Lee Webber) (1996-07-20)
Re: failure due to compiler? (Ian Moor) (1996-07-20)
Re: failure due to compiler? (1996-07-20)
Re: failure due to compiler? (Dara Gallagher) (1996-07-20)
Re: failure due to compiler? (1996-07-22)
Re: failure due to compiler? (1996-07-22)
Re: failure due to compiler? (Lee Webber) (1996-07-23)
Re: failure due to compiler ? (1996-07-23)
Re: failure due to compiler? (Eric Hamilton) (1996-07-23)
Re: failure due to compiler? (1996-07-23)
Re: failure due to compiler? (1996-07-24)
Re: failure due to compiler? (1996-07-26)
[2 later articles]
| List of all articles for this month |

From: (Ronald F. Guilmette)
Newsgroups: comp.compilers
Date: 22 Jul 1996 10:53:46 -0400
Organization: Infinite Monkeys & Co.
References: 96-07-041 96-07-100 96-07-123 96-07-141
Keywords: errors (G. Herrmannsfeldt) writes:
> I think my usual favorite, though I can't remember any exact examples,
> are ones that give the right answer only when extra debugging code is
> added, or when using a debugger.

I encountered one of these real recently.

Boy those chap my hide!

It was with the GNU C compiler. I was on a LynxOS system at the time.

I was getting fatal errors in the (GNU) linker. You can use the -v
option to gcc to see exactly how it is invoking the linker program.
I did that and then ran the same ``linker'' program with the exact
same command line options under GDB and the problem disappeared.

I dug deeper and found the cause of this enigma.

The ``linker'' program which was being executed was actually this other
GNU program called ``collect2'' which acts kind of like a meta-linker.
It invokes the linker for you, and then if some other post-link C++
magic needs to happen, it performs that magic and finally yields a
completed executable file.

Well, wouldn't you know it. Unbeknownst to me, the top-level `gcc'
driver program was setting up some environment variables before it
invoked collect2, and these environment variables affected the behavior
of the collect2 program in a rather dramatic way. Specifically, one of
these environment variables told collect2 where to go looking for the
_real_ linker.

The value that gcc was setting up in this environment variable was wrong,
so collect2 was invoking the wrong damn linker... and this was causing
the fatal errors. But when I was running collect2 directly under GDB
myself, I didn't have those environment variables set, so guess what?
Collect2 found the _right_ linker in this case, and all worked flawlessly.

Another very annoying mystery solved.

So remember kids, there may often be good (but obscure) reasons why things
start to work right when you try watching them closely (e.g. in a debugger).

P.S. I mentioned this episode to a collegue of mine, and he said that some
folks he works with calls these sorts of things ``Heisenbugs'', because they
are influenced by the very act of watching them.
-- Ron Guilmette, Roseville, CA --
---- E-mail: -----

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.