Help needed with Big List of Dodgy Apps

Robert Kiesling
Fri Sep 7 14:59:00 GMT 2007

> Jim Kleckner wrote:
> > Dave Korn wrote:
> [...]
> >>  I'm adding code to cygcheck to detect whether any of the software
> that has
> >> been known at some time to cause these kinds of problems are
> installed on
> >> the target system being cygchecked.
> [...]
> > Do you think a "tester" for API sanity is possible?
> > i.e. make some known good calls and assert their return values or some
> such.
> > Is there a common way that the badly designed hooking dlls cause
> problems
> > or is each one quite different?
> Yes, this would be very useful alone or in combination:
>  Detected current or previous Frobulator AV installation:
>  Some versions have been known to interfere with Cygwin.
>  Checking for known problems caused by this software...
>  No known interferences have not been detected, although
>  if you run into any of the following symptoms, you
>  should start by *completely uninstalling* the suspect
>  software and trying again (simply disabling it will
>  likely not correct the problem):
>   ...
> The problem with an Embedded Big List of Dodgy Apps is
> that any software that automatically updates itself
> could at any time suddenly start or stop interfering.
>  Warning: you are running Windows, so it is likely
>  that there is at least one Dodgy App hanging around
>  somewhere. Please reboot and reinstall everything.

Even without having looked at the Cygwin lib sources, I would have to 
say that the idea sounds useless, if the app is linked against a library, 
or library wrapper, that is constantly being patched.  

The Linux malloc man page, near the bottom, describes the MALLOC_CHECK_ 
environment variable.  If you have it handy, you might look at it.  This 
mechanism is the hook into the library for debugging tools like cfence, 
and other memory checkers.  Any check for apps that might have been 
shoehorned into the environment also need to check for events like
the signals that the Windows DLLs issue.  I'm told that Windows, for 
example, traps SIGSEGV, while UNIX, of course, does not.  UNIX apps that
can't cope with their environment, because of some spurious event, 
terminate with a core dump.  

Without that sort of information, the testing methods would be too random
and slipshod to make any sort of diagnoses.  

Not trying to be too cynical about this.  But I'd have a look at the
Cygwin DLLs and have a go at this kind of debugging tool, if anyone is


Ctalk Home Page:

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list