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