Mail Archives: cygwin/2003/04/30/18:30:25
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...
> 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?
'type -a gdb' from bash. You might have an alias or a shell function
defined...
Igor
> 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
> >
> >
>
>
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Knowledge is an unending adventure at the edge of uncertainty.
-- Leto II
--
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/
- Raw text -