This is the mail archive of the 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: [BUG] Intermittant error referencing memory @0x00000010

ERIC KRAUSE (ekraus02) wrote:

David A. Cobb writes:

Thanks, Eric.
Uname: CYGWIN_NT 5.0 .... 1.3.12 ( 2002-07-06 02:16
Complete CYGCHECK output appended (.zip)

For some reason the attached file only contained a reiteration of the uname

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:
Bug reporting:

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