This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin-gcc-fopen bug? (Purify)

Dave Korn wrote:
-----Original Message-----
From: cygwin-owner On Behalf Of Lester Ingber
Sent: 10 December 2004 16:14
  Your code has a bug: a stray pointer or array overwrite that is trashing some
memory.  The only reason you get away with it on Solaris is by sheer luck;
either the stack or heap layout is different, or the random uninitialised
contents of a variable point somewhere harmless or something like that.

  Since you can see a NUL (heh, NULL != NUL you know!) appearing in the middle
of the name string, you could always set a gdb watchpoint on it to see exactly
when it gets stomped and what instruction is doing it.

We used to use Purify to find these sorts of problems often just by running the program once. Unfortunately for us using cygwin, Purify appears to have moved toward a firm dependence on VC. Also, it is quite expensive.

However, since you say that you use Solaris you
may be able to use it on that platform.  Often,
the trial period is all you need to find that
pesky problem (and probably a host of others
in the process...).

 Trial for Unix:
 Trial for Win:

One concern is that I recall that they
may not be using their very strong
"object code insertion" technique on Unix
any longer and, without that, Purify becomes
fairly similar to BoundsChecker.

Has anyone out there gotten either Purify
or BoundsChecker to work with Cygwin?
I'll wager that if you could, Purify would
pinpoint a lot of tricky issues extremely
quickly.  Maybe a tool to munge the symbol
table into VC-compatible form?


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]