Help needed with Big List of Dodgy Apps

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Fri Sep 7 17:57:00 GMT 2007


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.

>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.

cgf

--
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/



More information about the Cygwin mailing list