Re: Help needed with Big List of Dodgy Apps

[Robert Kiesling <kiesling at earthlink dot net>]

> On Fri, Sep 07, 2007 at 09:55:26AM -0400, Robert Kiesling wrote:
> >> 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.
> 
> ?  I don't know what this means but Windows has the equivalent of SIGSEGV.

The signal is non-catchable by UNIX apps.  That ability would
be useful when malloc goes whizzing off into the video RAM, but
the issue is almost always a bug somewhere else in the app.  That 
is not to say that the system libraries are perfect, of course.

> 
> >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
> >interested.
> 
> Implementing something on the order of MALLOC_CHECK_ would not address
> this problem.  Cygwin already has hooks like this but they would not
> help here.

With the amount of code that comprises Cygwin, it might be useful not 
only for the people who maintain applications, but also when patching
the libraries, to have a lower-level database of most frequently
used library functions, and software failures that occur when using
them, which might be a more useful set of data when porting or upgrading, 
as the software faults would seem to occur at the level of the library
function calls, which it usually seems to be here.

Regards


Ctalk Home Page:  http://ctalk-lang.sourceforge.net/.






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/