Re: [BUG] Intermittant error referencing memory @0x00000010

["David A. Cobb" <superbiskit at cox dot net>]

ERIC KRAUSE (ekraus02) wrote:

> David A. Cobb writes:
>  
> > Thanks, Eric.
> >    Uname: CYGWIN_NT 5.0  .... 1.3.12 (0.54.3.2) 2002-07-06 02:16
> >    Complete CYGCHECK output appended (.zip)
> >    
> For some reason the attached file only contained a reiteration of the uname
> output.
Tried Again!

>  
> >    Another datapoint: I tried firing up CYGSERVER and doing the make.
> > Aha!  It ran to completion -- still errors of some sort but none of the
> > Win exceptions.
> >    That introduced other troubles, I'll post that later and try to keep
> > this thread focused.
> >    The other thing was terminating all the many aps I have in the
> > system tray (   except ZA and my antivirus ) and then keeping my hands
> > off while it ran so nothing was perturbing the memory allocations.
> >    Having CYGSERVER change things so completely makes me suspect that
> > IPC is related to the problem -- I don't know what else changes when the
> > server is active; also watching a ProcessExplorer display shows the
> > server IPC resources very very active.
> >
> >    
> How far into configure did you get before it crashed the first time?  That
> may shed some insight into why it's crashing.  Now your crash was in sh.exe
> right?  Cygwin /bin/sh isn't bash--it's the not-so-heavy simpler "ash".
>
> Were you using the "20020131-1" version?  If yes, I'd upgrade "ash" then try
> again without cygserver.
>
> ---
> Eric R. Krause
>  
It varies!  One thing, however, that is pretty consistant:  when configure freezes up, the "active" process is rm.exe, spawned by sh.exe.  This even happened once when a parameter error caused the configure script to fail; assuming that happened within maybe 10-minutes, the rm.exe hung around for 3-hours while I went away and came back.  Then I did something really strange: I fired off a second terminal session and ran gdb, attaching to the rm.exe process.  The EIP is way up in Microsoft land: 0x77f9f9e0.  Slightly more interesting, there are three active threads - and they are all up in high memory [below].  It's hard to see how much rm.exe is going to benefit from multiple threads.  But the result makes me wonder.  We know BG and friends made many compromises in their NT design to get better performance - things that should probably not be in ring-0 are there 'cause state transitions are so darn expensive.  And, I wouldn't be surprised, stuff is in a vulnerable place in ring-3 'cause it's quicker there.  ANYWAY, is it possible that we have re-entered a function that is not re-entrant?

THREADS from rm.exe [GDB display]

*3 <pid> 0x410 [eip=]0x77f9f9e0
2 <pid> 0x7EC ......0x77f87e77
1 <pid> 0x36C ......0x77f8b5bf

Another, slightly wierd thing: if I watch carefully while banging on Ctl+C, the process-id switches between two incarnations of rm.exe.
pid=1324/1472/1324/1472 etc.  Now, I don't know whether pids get reused that quickly!  But this looks like a classical deadly embrace.  The same sort of suggestion comes from watching rm.exe's handles from ProcessExplorer.  When it's stuck it keeps activating and then killing handles on one single /tmp/ directory.  It seems it is trying to get control of some resource, being denied, and not quite knowing what to do.  As in retrying when the status != EAGAIN(?)  
I'd be happy to try debugging more or something, but my C is decidedly rudimentary.  I'd probably do more harm than good.


--
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.

Attachment: cygcheck-2002-09-15.ZIP
Description: Zip compressed data

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/