Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Thu, 11 Aug 2005 12:33:05 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: "Segmentation fault" CygWin tools with code Injection-MS Detours Message-ID: <20050811163305.GB6935@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <42FB7644 DOT 8020905 AT le-resistant DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42FB7644.8020905@le-resistant.com> User-Agent: Mutt/1.5.8i On Thu, Aug 11, 2005 at 06:01:08PM +0200, Louis Lecaroz wrote: >I tried to LD_PRELOAD my Microsoft DLL Hook, & it appears to work, >cygwin is loaded correctly, & code is not injected but loaded by cygwin. & >Hooks appears working ! that's a great improvement on my issue. So it >appears to be the code injection from one process to another one which >is doing crashing cygwin tools ! > >But..... The LD_PRELOAD is only done one time when loading the first >instance of bash ! WOW! >if starting another instance of a cygwin tool under bash, I can see in >my traces a createprocess on bash itself before loading the child process. >I suppose bash forking itself before spawning the child process (ls.exe >for exemple). & because the forked process is initiliazed by a >setjmp/longjmp, the LD_PRELOAD not read in the forked instance (due to >entry point moved by the fork() methode of cygwin)... > >Am I wrong or right ? I can't really tell from your description. It looks like the LD_PRELOAD stuff won't be called in the forkee, but I don't know if that's what you're seeing or not. It still works when a process is execed, so it seems like it should be working most of the time. I've fixed this in CVS. I'll generate a snapshot with this change today. >If yes, & if it is possible to correct this special really interresting >undocumented CygWin Feature, I think, it will allow me to trace systems >Win32 native call (not cygwin call like strace), in all cygwin tools. Sorry, but no, this is a cygwin-only solution. It doesn't work with non-cygwin DLLs. 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/