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: Wed, 30 Apr 2003 18:47:11 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: App w/excessive soft page faults Message-ID: <20030430224711.GA2014@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i On Wed, Apr 30, 2003 at 06:30:06PM -0400, Igor Pechtchanski wrote: >On Wed, 30 Apr 2003, Brian Ford wrote: > >> Ok, I was able to find the stricmp calls by setting a break point in gdb. >> They were coming from either wglMakeCurrent or wglSwapLayerBuffers. I >> can only vaguely imagine why these are causing page faults, though. >> >> Interstingly enough, "info function stricmp" returns: >> 0x77f520c0 ntdll!_stricmp >> 0x77f520c0 stricmp >> 0x77c422a2 msvcrt!_stricmp >> 0x77c422a2 stricmp >> >> Yet "break stricmp" or "break 'ntdll!_stricmp'" return: >> Breakpoint 1 at 0x77f78f67 >> >> Notice the address? This is actually in tan(). >> >> "break 'msvcrt!_stricmp'" returns the a more proper: >> Breakpoint 1 at 0x77c422a7 >> >> Incidentally, the one being used was the former. > >Try setting the breakpoint at the exact function address. You will have >to step through assembly, but since all you really want is a backtrace... FWIW, you can do that with a "break *stricmp". 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/