X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 7 Sep 2007 13:57:12 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Help needed with Big List of Dodgy Apps Message-ID: <20070907175712.GA8852@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4C89134832705D4D85A6CD2EBF38AE0F012319CA AT PAUMAILU03 DOT ags DOT agere DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/