This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: App w/excessive soft page faults


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.

The RtlTimeFieldsToTime calls are still alluding me.  MSDN says these are
Driver Support Routines.  That probably explains why breakpoints aren't
working.  Must be inside the ATI Radeon drivers?

On a side note, and my gdb may be out of date (20030303-1), when I start
it, it always goes into the background and I must fg to get it back.
CYGWIN="tty ntsec"  Anyone else have this issue?

Thanks for the help.

On Wed, 30 Apr 2003, Igor Pechtchanski wrote:

> On Wed, 30 Apr 2003, Brian Ford wrote:
>
> > I tried setting a break point on RtlTimeFieldsToTime and
> > RtlTimeFieldsToTime+0x3dd.  They never triggered.
> >
> > Do breakpoints in dlls work?
>
> Yes, they do.
>
> You might try getting a debug version of cygwin1.dll with sources and
> setting a breakpoint in stricmp (which is part of newlib, I believe)...
> 	Igor
>
> > On Wed, 30 Apr 2003, Elfyn McBratney wrote:
> >
> > > > I have an app that is generating excessive soft page faults 500-700+/sec.
> > > > pfmon shows they happen here:
> > > >
> > > > SOFT: RtlTimeFieldsToTime+0x3dd : 0a7cb004
> > > > SOFT: stricmp+0x2f6 : 0a7da3ac
> > > >
> > > > This pattern repeats endlessly.
> > > >
> > > > We probably do make a lot of time related calls, but is this page faulting
> > > > behavior "normal"?  Any idea of how to track this back through cygwin1.dll
> > > > and into my app?  Thanks.
> > >
> > > First you need to compile your application with debugging symbols (the '-g'
> > > flag to gcc/c++). Once you've done that you can start your program under gdb
> > > like so
> > >
> > > $ gdb /path/to/app.exe
> > > (gdb) run [put any args here]
> > >
> > > and you can then issue the 'bt' command to gdb to get the backtrace, or if
> > > you suspect the problem is occurring inside the (Cygwin) DLL you can do
> > >
> > > (gdb) dll cygwin1
> > > (gdb) thread 1
> > > (gdb) bt
> > >
> > > this... I may have some of the above wrong (?).
> > > Elfyn
>
>

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]