This is the mail archive of the cygwin 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]

Running getent in a certain way grows it in memory in critical way.


Hi,

DISCLAIMER

If what I am about to report is reproducible, please do not try this
on a whim. The result for my Windows 7 64-bit OS was to exhaust all
available memory and stall the system to be unusable. In one instance,
this resulted in Windows/chkdsk doing a full scan of C: drive on
bootup.

I noticed getent on my 64-bit install for the first time today.
Excited (as I often type it into a Cygwin window, force of habit, to
no avail), I successfully ran; getent hosts www.google.com.au.

I then decided to check the usage:

getent --help

It printed the first bit of blurb (taken from a Debian system, as I'm
not about to try this again on Cygwin, but it should be equivalent):

$ getent --help
Usage: getent [OPTION...] database [key ...]
Get entries from administrative database.

  -i, --no-idn               disable IDN encoding
  -s, --service=CONFIG       Service configuration to be used
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

At this point, there was no more output. Instead the harddrive started
thrashing and Windows stalled almost to a standstill. Every now and then
I could get the mouse cursor to move.

Luckily I had a Process Explorer running, and somehow I was able to
Alt-Tab and inch my way to it, take a snapshot and kill getent. getent
had grown quickly to hold ~6GB of Private Bytes.

Here's the snapshot:

http://imgur.com/2Le98sz

Not believing what I had seen, I downloaded the code and checked it. I
inspected more_help() function, and suspecting the for loop my have
runaway, I eyed it over. It looks fine to me. I did notice
open_memstream(), and because I'm not familiar with its usage, I didn't
give it too much thought. I now think the method of dynamically growing
memory allocation may be a culprit. But I get ahead of myself.

I gave it another go. This time I could not alt-tab/inch my way back,
despite trying for several minutes. I had to hard reset the PC, and on
restart wait for a full chkdsk of the c: drive.

Thinking I might be able to get a hint of what was going wrong before I
reported the problem, I restarted, and attempted to single-step through
the more_help() function.

I need to recompile -O2 -> -O0 as the integer counters were optimised
out. Then single-stepping through, run --help succeed. But an attempt
to run ./getent --help on this non-optimised build encountered the same
problem. I had to hard reset to recover.

My gut is telling me that this will be some kind of race condition with
the dynamically allocated memory. As the problem didn't present when the
code was slowed down via single-step debug. But as I said, I don't know
enough about this technique to confirm.

I've attached cygcheck.out. Obviously, I will refrain from running
getent --help until otherwise advised.

--
Regards,
Shaddy

Attachment: cygcheck.out
Description: Text document

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

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