cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

Tue Jul 13 16:21:00 GMT 2004

On Tue, 13 Jul 2004, Dave Korn wrote:

> > -----Original Message-----
> > From: Igor Pechtchanski
> > Sent: 13 July 2004 16:41
>
> > On Tue, 13 Jul 2004, Dave Korn wrote:
> >
> > > > -----Original Message-----
> > > > From: cygwin-owner On Behalf Of Corinna Vinschen
> > > > Sent: 13 July 2004 16:20
> > >
> > > > David,
> > > >
> > > > since that doesn't look too good, I tried it on NT4 SP6 as well as
> > > > on XP SP1.  I can't reproduce the below problems in either system.
> > > > Does that only happen on W2K perhaps?  Depending on the SP?
> > > >
> > > > Corinna
> > >
> > > XP, SP1.  But I haven't upgraded my .dll in a while:
> > >
> > > dk@mace /davek> uname -a
> > > CYGWIN_NT-5.1 mace 1.5.7(0.109/3/2) 2004-01-30 19:32 i686 unknown unknown Cygwin
> > >
> > > I notice however that Reini is using 1.5.10, so it's not just a version
> > > thing.  I'll try building cvs and see if it still happens.
> >
> > Umm, Dave, I think you may be confused.
>
>   Nope, not really.  Or not for that reason, anyway!
>
> >  Reini's issue was that "cat
> > /proc/registry/HKEY_PERFOMANCE_DATA" (yes, I didn't notice the typo
> > before, interesting)
>
>   You also made a typo of your own there: he wasn't reading the key
> "/proc/registry/HKEY_PERFOMANCE_DATA" but the default *value* for that key,
> indicated by "/proc/registry/HKEY_PERFOMANCE_DATA/@"

Yep, I noticed this after I sent the message, but that didn't change the
point of the comment, so I didn't bother to correct it.  FWIW, another
interesting fact is that on my system, "ls HKEY_PERFOMANCE_DATA" from
/proc/registry prints "@  @" (i.e., *two* default values), neither of
which can be stat()ed.

> >didn't terminate, which I, after reading MSDN,
> > believe to be perfectly valid behavior.  He wasn't getting
> > any segfaults.
>
>   I know.  I didn't say he was (getting segfaults).  I just pointed out
> a couple of interesting things I discovered while trying to reproduce
> his bug. I also explained why your interpretation of MSDN was incorrect.

Right, I interpreted the key as a stream (which is actually what "cat"
does), and you're right that at the low level keys aren't streams, so that
paradigm shift happens somewhere in the /proc/registry fhandler.
However...

> A registry key simply isn't something you can go on and on reading from.

This is where you're wrong.  Here's an excerpt from the MSDN documentation
on RegQueryValueEx
(<http://msdn.microsoft.com/library/en-us/sysinfo/base/regqueryvalueex.asp>):

	If hKey specifies HKEY_PERFORMANCE_DATA and the lpData buffer is
	not large enough to contain all of the returned data,
	RegQueryValueEx returns ERROR_MORE_DATA and the value returned
	through the lpcbData parameter is undefined.  This is because the
	size of the performance data can change from one call to the next.
	In this case, you must increase the buffer size and call
	RegQueryValueEx again passing the updated buffer size in the
	lpcbData parameter.  Repeat this until the function succeeds.
	You need to maintain a separate variable to keep track of the
	buffer size, because the value returned by lpcbData is
	unpredictable.

So, in effect, you *do* need to treat HKEY_PERFORMANCE_DATA specially, and
the /proc/registry fhandler in fact does.  Also, I think I may have found
the source of the bug.  See below.

> There isn't a single key anywhere in the registry that has any kind of
> EOF whatsoever, so the lack of one on this particular key can't make the
> difference.

True, I apologize for the wrong terminology.

> I didn't get around to trying the actual cat instruction he quoted.
> I'll try it now:
>
> dk@mace ~> cat /proc/registry/HKEY_PERFOMANCE_DATA
> Segmentation fault (core dumped)
> dk@mace ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
>
>   And then it hangs, as described.  Takes (up to) 100%cpu, as well.  However
> I find that unlike Reini, I can kill it easily enough:
>
>   [Window 1]
> dk@mace ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
>   [Hangs.  Meanwhile in window 2:]
> dk@mace ~> ps
>       PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
> [snip]
>      2596    3884    2596       1672  con 11165 16:46:07 /usr/bin/cat
>      3380    4008    3380       2280  con 11165 16:46:26 /usr/bin/ps
> dk@mace ~> kill 2596
> dk@mace ~>
>     [And back in window 1:]
> dk@mace ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
> Terminated
> dk@mace ~>
>
> > FWIW, I can't reproduce your segfaults either, on Win2k SP3, but I can
> > reproduce the behavior Reini reported.
> > 	Igor
>
>   Well, I get the segfaults *and* Reini's bug.  Guess I'm just lucky!

You will have to debug the segfaults yourself.  As for the source or the
"Reini bug", this piece of code from fhandler_registry.cc looks
suspicious, in particular, the line marked with "==>" (line 576):

  else
    {
      bufalloc = 0;
      do
        {
==>       bufalloc += 1000;
          filebuf = (char *) realloc (filebuf, bufalloc);
          error = RegQueryValueEx (handle, value_name, NULL, &type,
                                   (BYTE *) filebuf, &size);
          if (error != ERROR_SUCCESS && error != ERROR_MORE_DATA)
            {
              if (error != ERROR_FILE_NOT_FOUND)
                {
                  seterrno_from_win_error (__FILE__, __LINE__, error);
                  return true;
                }
              goto value_not_found;
            }
        }
      while (error == ERROR_MORE_DATA);
      filesize = size;
    }

I have a theory that the performance data may be added in chunks larger
than 1000 bytes, so the fhandler just can't keep up with the amount of
data, and loops indefinitely.  Since you intend to build the DLL from CVS,
you're probably in the best position to check whether this theory is true
(by either just upping the increment amount to something like 5000, or
even doubling the buffer size on each iteration).  If you can't do this,
I'll get to building the DLL tonight and do the above check.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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