cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Reini Urban]

cat /proc/registry/HKEY_PERFOMANCE_DATA/@
hangs forever.

Win2K (no win98 OS)
Shouldn't HKEY_PERFOMANCE_DATA be disabled on NT systems, or does it work?

This cat has pid 560:
$ cat /proc/560/status
Name:   cat
State:  R (runnable)
Tgid:   560
Pid:    560
PPid:   1956
Uid:    1000 1000 1000 1000
Gid:    544 544 544 544
VmSize:    40940 kB
VmLck:         0 kB
VmRSS:     28208 kB
VmData:    27980 kB
VmStk:         0 kB
VmExe:        16 kB
VmLib:       192 kB
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000

kill 560
doesn't help, /bin/kill.exe neither.
pskill works ok.

$ uname -a
CYGWIN_NT-5.0 reini 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown 
unknown Cygwin
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Tue, 13 Jul 2004, Reini Urban wrote:

> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
> hangs forever.

According to MSDN
(<http://msdn.microsoft.com/library/en-us/perfmon/base/the_hkey_performance_data_key.asp>):

	...although you use the registry to collect performance data, the
	data is not stored in the registry database.  Instead, calling the
	registry functions with the HKEY_PERFORMANCE_DATA key causes the
	system to collect the data from the appropriate system object
	managers.

	To obtain performance data from the local system, use the
	RegQueryValueEx function, with the HKEY_PERFORMANCE_DATA key.
	The first call opens the key; you do not need to explicitly open
	the key first.  However, be sure to use the RegCloseKey function
	to close the handle to the key when you are finished obtaining
	performance data.

This tells me that reading from HKEY_PERFORMANCE_DATA never returns EOF,
so that you have to terminate it explicitly from the outside.  So your
behavior sounds absolutely normal.

> Win2K (no win98 OS)
> Shouldn't HKEY_PERFOMANCE_DATA be disabled on NT systems, or does it work?

If the key is present, it'll be in /proc/registry.  FWIW, the MSDN web
page above doesn't mention any restrictions on the systems that this key
is present on.

> This cat has pid 560:
> $ cat /proc/560/status
> [snip]
>
> kill 560
> doesn't help, /bin/kill.exe neither.
> pskill works ok.

"/bin/kill -f 560".

> $ uname -a
> CYGWIN_NT-5.0 reini 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown
> unknown Cygwin

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Igor Pechtchanski
> Sent: 13 July 2004 15:30
> To: Reini Urban

> On Tue, 13 Jul 2004, Reini Urban wrote:
> 
> > cat /proc/registry/HKEY_PERFOMANCE_DATA/@
> > hangs forever.
> 
> According to MSDN
> (<http://msdn.microsoft.com/library/en-us/perfmon/base/the_hke
y_performance_data_key.asp>):

[snip]

> This tells me that reading from HKEY_PERFORMANCE_DATA never 
> returns EOF,
> so that you have to terminate it explicitly from the outside.  So your
> behavior sounds absolutely normal.

  Reading a registry key isn't like reading a stream.  There's no file
position pointer and no EOF mark.  You read all (or as much as you want) of
the data in one operation.  I don't think this failure mode seems likely.

> > Win2K (no win98 OS)
> > Shouldn't HKEY_PERFOMANCE_DATA be disabled on NT systems, 
> or does it work?
> 
> If the key is present, it'll be in /proc/registry.  FWIW, the MSDN web
> page above doesn't mention any restrictions on the systems 
> that this key
> is present on.

Heh.  Check this:

dk@mace ~> cd /proc/registry/
dk@mace /proc/registry> ls
HKEY_CLASSES_ROOT    HKEY_CURRENT_USER  HKEY_LOCAL_MACHINE    HKEY_USERS
HKEY_CURRENT_CONFIG  HKEY_DYN_DATA      HKEY_PERFOMANCE_DATA
dk@mace /proc/registry> ls -la
Segmentation fault (core dumped)
dk@mace /proc/registry>

next I type 'ls' <space> <tab> to get

dk@mace /proc/registry> ls HKEY_

then I press P <tab> and the bash window vanishes !!


And check this too:

dk@mace /proc/registry> getfacl HKEY_PERFOMANCE_DATA
Segmentation fault (core dumped)
dk@mace /proc/registry> getfacl *
# file: HKEY_CLASSES_ROOT
# owner: Administrators
# group: SYSTEM
user::r-x
group::r-x
other:---
mask:rwx

# file: HKEY_CURRENT_CONFIG
# owner: Administrators
# group: SYSTEM
user::r-x
group::r-x
other:---
mask:rwx

# file: HKEY_CURRENT_USER
# owner: Administrators
# group: SYSTEM
user::r-x
group::r-x
other:---
mask:rwx

# file: HKEY_DYN_DATA
# owner: dk
# group: Domain Users
user::r-x
group::r-x
other:r-x
mask:rwx

# file: HKEY_LOCAL_MACHINE
# owner: Administrators
# group: SYSTEM
user::r-x
group::r-x
other:r--
mask:rwx
Segmentation fault (core dumped)
dk@mace /proc/registry>

  There's something badly wrong: it seems that any attempt to stat or
otherwise access it causes a segfault.

  Tell me, do you suppose the spelling mistake between HKEY_PERFOMANCE_DATA
and HKEY_PERFO*R*MANCE_DATA could be resulting in some internal routine in
cygwin's registry->filesystem mapping code getting called with a NULL
pointer?



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Corinna Vinschen]

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


On Jul 13 16:07, Dave Korn wrote:
> Heh.  Check this:
> 
> dk@mace ~> cd /proc/registry/
> dk@mace /proc/registry> ls
> HKEY_CLASSES_ROOT    HKEY_CURRENT_USER  HKEY_LOCAL_MACHINE    HKEY_USERS
> HKEY_CURRENT_CONFIG  HKEY_DYN_DATA      HKEY_PERFOMANCE_DATA
> dk@mace /proc/registry> ls -la
> Segmentation fault (core dumped)
> dk@mace /proc/registry>
> 
> next I type 'ls' <space> <tab> to get
> 
> dk@mace /proc/registry> ls HKEY_
> 
> then I press P <tab> and the bash window vanishes !!
> 
> 
> And check this too:
> 
> dk@mace /proc/registry> getfacl HKEY_PERFOMANCE_DATA
> Segmentation fault (core dumped)
> dk@mace /proc/registry> getfacl *
> # file: HKEY_CLASSES_ROOT
> # owner: Administrators
> # group: SYSTEM
> user::r-x
> group::r-x
> other:---
> mask:rwx
> 
> # file: HKEY_CURRENT_CONFIG
> # owner: Administrators
> # group: SYSTEM
> user::r-x
> group::r-x
> other:---
> mask:rwx
> 
> # file: HKEY_CURRENT_USER
> # owner: Administrators
> # group: SYSTEM
> user::r-x
> group::r-x
> other:---
> mask:rwx
> 
> # file: HKEY_DYN_DATA
> # owner: dk
> # group: Domain Users
> user::r-x
> group::r-x
> other:r-x
> mask:rwx
> 
> # file: HKEY_LOCAL_MACHINE
> # owner: Administrators
> # group: SYSTEM
> user::r-x
> group::r-x
> other:r--
> mask:rwx
> Segmentation fault (core dumped)
> dk@mace /proc/registry>
> 
>   There's something badly wrong: it seems that any attempt to stat or
> otherwise access it causes a segfault.
> 
>   Tell me, do you suppose the spelling mistake between HKEY_PERFOMANCE_DATA
> and HKEY_PERFO*R*MANCE_DATA could be resulting in some internal routine in
> cygwin's registry->filesystem mapping code getting called with a NULL
> pointer?
> 
> 
> 
>     cheers, 
>       DaveK
> -- 
> Can't think of a witty .sigline today....
> 
> 
> --
> 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/

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Co-Project Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

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

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

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.  Reini's issue was that "cat
/proc/registry/HKEY_PERFOMANCE_DATA" (yes, I didn't notice the typo
before, interesting) didn't terminate, which I, after reading MSDN,
believe to be perfectly valid behavior.  He wasn't getting any segfaults.
FWIW, I can't reproduce your segfaults either, on Win2k SP3, but I can
reproduce the behavior Reini reported.
	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/

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

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

>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.  A registry
key simply isn't something you can go on and on reading from.  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.  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
I    2464       1    2464       2464  con 11165 11:44:15 /usr/bin/bash
     3908       1    3908       3908  con 11165 16:03:39 /usr/bin/bash
      780    3908     780       3628  con 11165 16:34:03 /usr/bin/make
I    1028    3908     780       1076  con 11165 16:34:03 /usr/bin/tee
     3884       1    3884       3884  con 11165 16:45:18 /usr/bin/bash
     4008       1    4008       4008  con 11165 16:45:20 /usr/bin/bash
     2736     780     780       2772  con 11165 16:45:25 /usr/bin/sh
     3132    2736     780       2340  con 11165 16:45:25 /usr/bin/make
      244    3132     780       2440  con 11165 16:45:25 /usr/bin/sh
     3720     244     780        180  con 11165 16:45:25 /usr/bin/make
     1692    3720     780       2172  con 11165 16:46:06 /usr/bin/sh
     2384    1692     780       2936  con 11165 16:46:06 /usr/bin/gcc
     3412    2384     780       3412  con 11165 16:46:07 /usr/bin/gcc
     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!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

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/

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Yitzchak Scott-Thoennes]

On Tue, Jul 13, 2004 at 12:21:50PM -0400, Igor Pechtchanski wrote:
>       bufalloc = 0;
>       do
>         {
> ==>       bufalloc += 1000;

> 
> 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).

Perhaps bufalloc += max(bufalloc, 1000);

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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Tue, 13 Jul 2004, Yitzchak Scott-Thoennes wrote:

> On Tue, Jul 13, 2004 at 12:21:50PM -0400, Igor Pechtchanski wrote:
> >       bufalloc = 0;
> >       do
> >         {
> > ==>       bufalloc += 1000;
>
> >
> > 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).
>
> Perhaps bufalloc += max(bufalloc, 1000);

Sorry, but no.  This will do nothing for the original problem.  The idea
was that at some point you need the rate of buffer size increase to
overtake the rate of performance data generation.  If performance data is
generated faster than 1000 bytes per query, and adding 1000 bytes isn't
enough, adding *at most* 1000 bytes (as you suggested) is strictly less
effective.  I suggested a linear function with a steeper slope (which may
not be enough) or an exponential, which will definitely be enough, but may
introduce huge buffers.

I'm going to build the DLL from CVS now to test the theory.  If it is
confirmed, then we can talk about a good buffer size increment function
(probably on cygwin-developers, though).
	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/

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Yitzchak Scott-Thoennes]

On Tue, Jul 13, 2004 at 06:20:19PM -0400, Igor Pechtchanski wrote:
> > Perhaps bufalloc += max(bufalloc, 1000);

Gack! I meant min() :)
 
> Sorry, but no.  This will do nothing for the original problem.  The idea
> was that at some point you need the rate of buffer size increase to
> overtake the rate of performance data generation.  If performance data is
> generated faster than 1000 bytes per query, and adding 1000 bytes isn't
> enough, adding *at most* 1000 bytes (as you suggested) is strictly less
> effective.  I suggested a linear function with a steeper slope (which may
> not be enough) or an exponential, which will definitely be enough, but may
> introduce huge buffers.

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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Tue, 13 Jul 2004, Yitzchak Scott-Thoennes wrote:

> On Tue, Jul 13, 2004 at 06:20:19PM -0400, Igor Pechtchanski wrote:
> > > Perhaps bufalloc += max(bufalloc, 1000);
>
> Gack! I meant min() :)

Ah, yes, that'd work (i.e., converge faster).  We might want to eventually
explore something in between linear and exponential, though. :-)
	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/

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Tue, 13 Jul 2004, Igor Pechtchanski wrote:

> On Tue, 13 Jul 2004, Yitzchak Scott-Thoennes wrote:
>
> > On Tue, Jul 13, 2004 at 06:20:19PM -0400, Igor Pechtchanski wrote:
> > > > Perhaps bufalloc += max(bufalloc, 1000);
> >
> > Gack! I meant min() :)
>
> Ah, yes, that'd work (i.e., converge faster).  We might want to eventually
> explore something in between linear and exponential, though. :-)
> 	Igor

Double gack!  max() was right.  I think we both reversed gears for a
moment there.

Move along folks, nothing to see here.
	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!

Ne.e..d m...o....r......e c........o...........f..............f.................

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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Yitzchak Scott-Thoennes]

On Tue, Jul 13, 2004 at 10:23:51PM -0400, Igor Pechtchanski wrote:
> On Tue, 13 Jul 2004, Igor Pechtchanski wrote:
> 
> > On Tue, 13 Jul 2004, Yitzchak Scott-Thoennes wrote:
> >
> > > On Tue, Jul 13, 2004 at 06:20:19PM -0400, Igor Pechtchanski wrote:
> > > > > Perhaps bufalloc += max(bufalloc, 1000);
> > >
> > > Gack! I meant min() :)
> >
> > Ah, yes, that'd work (i.e., converge faster).  We might want to eventually
> > explore something in between linear and exponential, though. :-)
> > 	Igor
> 
> Double gack!  max() was right.  I think we both reversed gears for a
> moment there.
> 
> Move along folks, nothing to see here.

:) Apparently I'm a little too persuadable.

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Tue, 13 Jul 2004, Igor Pechtchanski wrote:

> On Tue, 13 Jul 2004, Dave Korn wrote:
>
> [snip]
> > 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:
> >[snip]
> >   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

Ok, the theory washed out.  The code above is actually simply buggy.  When
RegQueryValueEx is called (2 lines below the arrow), the "size" parameter
is uninitialized, so, in effect, it keeps thinking that the buffer has
some random size and reallocating (which, of course, doesn't change the
size, hence the infinite loop).

However, the fix is not as simple as inserting a "size = bufalloc;" just
before the RegQueryValueEx.  When I do that, I get a SIGSEGV in the guts
of iasperf.dll, which I have yet to track down.  This happens on the
second iteration, FWIW, with buffer increment of 1000.  I'm going to
investigate some more, but I'd say that with the above bug, this key was
never tested, so I have no idea what's going on.  Hopefully Chris
(January) can use this to help him track down the problem.
	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/

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Reini Urban]

Igor Pechtchanski schrieb:

> On Tue, 13 Jul 2004, Reini Urban wrote:
> 
> 
>>cat /proc/registry/HKEY_PERFOMANCE_DATA/@
>>hangs forever.
> 
> 
> According to MSDN
> (<http://msdn.microsoft.com/library/en-us/perfmon/base/the_hkey_performance_data_key.asp>):
> 
> 	...although you use the registry to collect performance data, the
> 	data is not stored in the registry database.  Instead, calling the
> 	registry functions with the HKEY_PERFORMANCE_DATA key causes the
> 	system to collect the data from the appropriate system object
> 	managers.
> 
> 	To obtain performance data from the local system, use the
> 	RegQueryValueEx function, with the HKEY_PERFORMANCE_DATA key.
> 	The first call opens the key; you do not need to explicitly open
> 	the key first.  However, be sure to use the RegCloseKey function
> 	to close the handle to the key when you are finished obtaining
> 	performance data.
> 
> This tells me that reading from HKEY_PERFORMANCE_DATA never returns EOF,
> so that you have to terminate it explicitly from the outside.  So your
> behavior sounds absolutely normal.
> 
> 
>>Win2K (no win98 OS)
>>Shouldn't HKEY_PERFOMANCE_DATA be disabled on NT systems, or does it work?
> 
> 
> If the key is present, it'll be in /proc/registry.  FWIW, the MSDN web
> page above doesn't mention any restrictions on the systems that this key
> is present on.
> 
> 
>>This cat has pid 560:
>>$ cat /proc/560/status
>>[snip]
>>
>>kill 560
>>doesn't help, /bin/kill.exe neither.
>>pskill works ok.
> 
> 
> "/bin/kill -f 560".

$ cat /proc/registry/HKEY_PERFOMANCE_DATA/@

/bin/kill -f doesn't work.  (W2K SP4, all updates)

$ ps
       PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
      1432       1    1432       1432    0 1000 11:47:24 /usr/bin/bash
       636    1432     636       1724    0 1000 11:47:37 /usr/bin/cat
      1732       1    1732       1732    1 1000 11:49:10 /usr/bin/bash
      1772    1732    1772       1784    1 1000 11:49:14 /usr/bin/ps

$ /bin/kill -f 636
couldn't open pid 636

If the registry handler should follow the stream semantics it should 
react on signals at least.
But neither Ctrl-D nor Ctrl-C work.

next attempt: (still no killall script? then it would be simply killall cat)

$ /bin/kill -9 -f 1748
couldn't open pid 1748

but here cat and the parent bash windows are killed.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Wed, 14 Jul 2004, Reini Urban wrote:

> Igor Pechtchanski schrieb:
>
> > On Tue, 13 Jul 2004, Reini Urban wrote:
> >
> >>cat /proc/registry/HKEY_PERFOMANCE_DATA/@
> >>hangs forever.
> >
> > According to MSDN
> > (<http://msdn.microsoft.com/library/en-us/perfmon/base/the_hkey_performance_data_key.asp>):
> > [snip]
> >
> >>This cat has pid 560:
> >>$ cat /proc/560/status
> >>[snip]
> >>
> >>kill 560
> >>doesn't help, /bin/kill.exe neither.
> >>pskill works ok.
> >
> > "/bin/kill -f 560".

Whoops.  That's two errors in this thread.  This should have been the
Windows PID of cat.  *blush*.

> $ cat /proc/registry/HKEY_PERFOMANCE_DATA/@
>
> /bin/kill -f doesn't work.  (W2K SP4, all updates)
>
> $ ps
>        PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>       1432       1    1432       1432    0 1000 11:47:24 /usr/bin/bash
>        636    1432     636       1724    0 1000 11:47:37 /usr/bin/cat
>       1732       1    1732       1732    1 1000 11:49:10 /usr/bin/bash
>       1772    1732    1772       1784    1 1000 11:49:14 /usr/bin/ps
>
> $ /bin/kill -f 636
> couldn't open pid 636

You needed to say "/bin/kill -f 1724".  Mea culpa.

> If the registry handler should follow the stream semantics it should
> react on signals at least.
> But neither Ctrl-D nor Ctrl-C work.

See <http://cygwin.com/ml/cygwin/2004-07/msg00496.html>.  The
fhandler_registry::fill_filebuf function just gets into a tight infinite
loop with no chance for signal handling.

> next attempt: (still no killall script? then it would be simply killall cat)
>
> $ /bin/kill -9 -f 1748
> couldn't open pid 1748
>
> but here cat and the parent bash windows are killed.

Huh?  What's 1748?  Did you mean 1432?  Also, you either supply -9 or -f
(-9 sends Cygwin SIGKILL, -f uses TerminateProcess).

Sorry for the confusion.  Hope we'll get this sorted out eventually.
	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/

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Igor Pechtchanski
> Sent: 14 July 2004 04:22

> Ok, the theory washed out.  The code above is actually simply 
> buggy.  When
> RegQueryValueEx is called (2 lines below the arrow), the 
> "size" parameter
> is uninitialized, so, in effect, it keeps thinking that the buffer has
> some random size and reallocating (which, of course, doesn't 
> change the
> size, hence the infinite loop).

  I concur; that is bad code.  The variable unambiguously needs
initialising, and since RegQueryValueEx damages it, it needs to be re-set
each time round the loop.  

  I disagree with your analysis, though.  After the first time round the
loop, size is no longer uninitialised.  After all, the call to
RegQueryValueEx sets size to the amount of space needed.  Second time round
the loop, we set bufalloc to 2000, realloc that much space, then call
RegQueryValueEx, passing it the pointer to this 2000 byte buffer, and the
size variable is still whatever RegQueryValueEx set it to last time, i.e.
the full size of the value's data.  So when we call RegQueryValueEx the
second time, it thinks the buffer is loads bigger than it actually is - in
fact, it thinks the buffer is exactly big enough for the value's data - and
it copies waaaay more data into the buffer than it has room for.  Bang!
Heap corruption!

> However, the fix is not as simple as inserting a "size = 
> bufalloc;" just
> before the RegQueryValueEx.  When I do that, I get a SIGSEGV 
> in the guts
> of iasperf.dll, which I have yet to track down.  This happens on the
> second iteration, FWIW, with buffer increment of 1000.  

  That's funny.  It WFMHRN.  Are you completely sure that you put that line
in the right place?  Are you sure you remembered to rebuild the dll after
editing the source?  Are you sure you tested the new version of the dll
rather than some old one?  I know some of these things sound daft, but since
the fix is a) obviously correct, and b) tested and working, I suspect that
you made some little error in the procedure that invalidated your test.  You
wouldn't believe how often I ALT+TAB to another window and type "make all"
only to realise I haven't saved all the changed files that I have in my
editor window, only some of them!  In particular, the fact that you see a
SEGV the second time round - which is what my analysis above demonstrates
should happen if the size variable is NOT reinited each time round the loop
- makes me think you didn't actually test the right code.  You better
double-check.

  Just to show that the bug really is fixed by that one-line patch, here's a
dump of it WFMHRNing:

dk@mace ~/reg-test> ls -la
total 78
drwxr-xr-x+   2 dk       Domain U        0 Jul 14 17:44 .
drwxrwxrwx+   6 dk       Domain U        0 Jul 14 17:43 ..
-rw-r--r--    1 dk       Domain U    79264 Jul 14 17:44 test1.dat
dk@mace ~/reg-test> cat /proc/registry/HKEY_PERFOMANCE_DATA/@ >test2.dat
dk@mace ~/reg-test> cat /proc/registry/HKEY_PERFOMANCE_DATA/@ >test3.dat
dk@mace ~/reg-test> cat /proc/registry/HKEY_PERFOMANCE_DATA/@ >test4.dat
dk@mace ~/reg-test> ls -la
total 312
drwxr-xr-x+   2 dk       Domain U        0 Jul 14 17:44 .
drwxrwxrwx+   6 dk       Domain U        0 Jul 14 17:43 ..
-rw-r--r--    1 dk       Domain U    79264 Jul 14 17:44 test1.dat
-rw-r--r--    1 dk       Domain U    79264 Jul 14 17:44 test2.dat
-rw-r--r--    1 dk       Domain U    79264 Jul 14 17:44 test3.dat
-rw-r--r--    1 dk       Domain U    79264 Jul 14 17:44 test4.dat
dk@mace ~/reg-test>

  Here's the patch, against current CVS.  I'll let Igor supply the ChangeLog
entry, since it was his fix.

Index: winsup/cygwin/fhandler_registry.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_registry.cc,v
retrieving revision 1.24
diff -p -u -r1.24 fhandler_registry.cc
--- winsup/cygwin/fhandler_registry.cc  9 Feb 2004 04:04:23 -0000       1.24
+++ winsup/cygwin/fhandler_registry.cc  14 Jul 2004 16:47:53 -0000
@@ -575,6 +575,7 @@ fhandler_registry::fill_filebuf ()
        {
          bufalloc += 1000;
          filebuf = (char *) realloc (filebuf, bufalloc);
+          size = bufalloc;
          error = RegQueryValueEx (handle, value_name, NULL, &type,
                                   (BYTE *) filebuf, &size);
          if (error != ERROR_SUCCESS && error != ERROR_MORE_DATA)



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Corinna Vinschen]

On Jul 14 17:58, Dave Korn wrote:
> > -----Original Message-----
> > From: cygwin-owner On Behalf Of Igor Pechtchanski
> > Sent: 14 July 2004 04:22
> 
> > Ok, the theory washed out.  The code above is actually simply 
> > buggy.  When
> > RegQueryValueEx is called (2 lines below the arrow), the 
> > "size" parameter
> > is uninitialized, so, in effect, it keeps thinking that the buffer has
> > some random size and reallocating (which, of course, doesn't 
> > change the
> > size, hence the infinite loop).
> 
>   I concur; that is bad code.  The variable unambiguously needs
> initialising, and since RegQueryValueEx damages it, it needs to be re-set
> each time round the loop.  
> [...]

I'm wondering if that isn't mildly OT here.  Shouldn't that be discussed
on cygwin-developers in a perfect world?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Co-Project Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

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

[OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 14 July 2004 18:15

> On Jul 14 17:58, Dave Korn wrote:
> > > -----Original Message-----
> > > From: cygwin-owner On Behalf Of Igor Pechtchanski
> > > Sent: 14 July 2004 04:22
> > 
> > > Ok, the theory washed out.  The code above is actually simply 
> > > buggy.  When
> > > RegQueryValueEx is called (2 lines below the arrow), the 
> > > "size" parameter
> > > is uninitialized, so, in effect, it keeps thinking that 
> the buffer has
> > > some random size and reallocating (which, of course, doesn't 
> > > change the
> > > size, hence the infinite loop).
> > 
> >   I concur; that is bad code.  The variable unambiguously needs
> > initialising, and since RegQueryValueEx damages it, it 
> needs to be re-set
> > each time round the loop.  
> > [...]
> 
> I'm wondering if that isn't mildly OT here.  Shouldn't that 
> be discussed
> on cygwin-developers in a perfect world?
> 
> Corinna

  Well, the thread's more-or-less over now, I would have thought.  Still
expecting one more post from Igor saying "Yes, I was testing the wrong
version of the dll", and his changelog entry, but that should bring it to a
close.

  Still, I've sent in a subscription request anyway  [Note Cc!].  I've never
paid much attention to that list before.  I notice that even the list
archive is closed if you aren't subbed - surely that's a bit WJM?  I can
understand having subscribers-only posting rules, and I can understand
wanting to have only serious developers posting there, but I don't see why
it shouldn't be viewable and searchable for everyone else.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Wed, 14 Jul 2004, Corinna Vinschen wrote:

> On Jul 14 17:58, Dave Korn wrote:
> > > -----Original Message-----
> > > From: cygwin-owner On Behalf Of Igor Pechtchanski
> > > Sent: 14 July 2004 04:22
> >
> > > Ok, the theory washed out.  The code above is actually simply buggy.
> > > When RegQueryValueEx is called (2 lines below the arrow), the "size"
> > > parameter is uninitialized, so, in effect, it keeps thinking that
> > > the buffer has some random size and reallocating (which, of course,
> > > doesn't change the size, hence the infinite loop).
> >
> >   I concur; that is bad code.  The variable unambiguously needs
> > initialising, and since RegQueryValueEx damages it, it needs to be re-set
> > each time round the loop.
> > [...]
>
> I'm wondering if that isn't mildly OT here.  Shouldn't that be discussed
> on cygwin-developers in a perfect world?
>
> Corinna

Yes, but the world is not perfect, and if we move this thread to
cygwin-developers now, we'll lose thread continuity.  I'll do it if you
insist, though.  I'm about to reply to Dave, so please let me know.  :-)
	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/

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

Since Dave is not subscribed to cygwin-developers anyway, I'll continue
this here.  More below.

On Wed, 14 Jul 2004, Dave Korn wrote:

> > -----Original Message-----
> > From: cygwin-owner On Behalf Of Igor Pechtchanski
> > Sent: 14 July 2004 04:22
>
> > Ok, the theory washed out.  The code above is actually simply buggy.
> > When RegQueryValueEx is called (2 lines below the arrow), the "size"
> > parameter is uninitialized, so, in effect, it keeps thinking that the
> > buffer has some random size and reallocating (which, of course,
> > doesn't change the size, hence the infinite loop).
>
>   I concur; that is bad code.  The variable unambiguously needs
> initialising, and since RegQueryValueEx damages it, it needs to be
> re-set each time round the loop.

Not quite true.  Turns out RegQueryValueEx doesn't touch the value of size
if the buffer is too small (for HKEY_PERFORMANCE_DATA).  So size stayed at
0.

>   I disagree with your analysis, though.  After the first time round the
> loop, size is no longer uninitialised.  After all, the call to
> RegQueryValueEx sets size to the amount of space needed.

That is not true for HKEY_PERFORMANCE_DATA.  See MSDN
(<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.

> Second time round the loop, we set bufalloc to 2000, realloc that much
> space, then call RegQueryValueEx, passing it the pointer to this 2000
> byte buffer, and the size variable is still whatever RegQueryValueEx set
> it to last time, i.e. the full size of the value's data.  So when we
> call RegQueryValueEx the second time, it thinks the buffer is loads
> bigger than it actually is - in fact, it thinks the buffer is exactly
> big enough for the value's data - and it copies waaaay more data into
> the buffer than it has room for.  Bang! Heap corruption!

Hmm, did you verify this in gdb?  Mine showed size=0 until I added the
assignment.

> > However, the fix is not as simple as inserting a "size = bufalloc;"
> > just before the RegQueryValueEx.  When I do that, I get a SIGSEGV in
> > the guts of iasperf.dll, which I have yet to track down.  This happens
> > on the second iteration, FWIW, with buffer increment of 1000.
>
>   That's funny.  It WFMHRN.

"Works for me here right now"?

> Are you completely sure that you put that line in the right place?

Yes.

> Are you sure you remembered to rebuild the dll after editing the source?

Yes.

> Are you sure you tested the new version of the dll rather than some old
> one?

Yes.

> I know some of these things sound daft, but since the fix is a)
> obviously correct, and b) tested and working, I suspect that you made
> some little error in the procedure that invalidated your test.

...or we have some differences in user permissions, operating systems,
environments, setup, etc, etc, etc.  In any case, the above does *NOT*
work for me.

> You wouldn't believe how often I ALT+TAB to another window and type
> "make all" only to realise I haven't saved all the changed files that I
> have in my editor window, only some of them!

I'm reasonably sure I've rebuilt everything from scratch (I even did a
"make clean" - ouch).

> In particular, the fact that you see a SEGV the second time round -
> which is what my analysis above demonstrates should happen if the size
> variable is NOT reinited each time round the loop - makes me think you
> didn't actually test the right code.  You better double-check.

Triple-checked.  Your analysis would have been correct for any key but
HKEY_PERFORMANCE_DATA.

>   Just to show that the bug really is fixed by that one-line patch,
> here's a dump of it WFMHRNing:
> [snip]

I believe you.  It just doesn't work for me. :-(  In fact, I'm getting a
segfault whenever the RegQueryValueEx call attempts to write anything to
a buffer, whether realloc()'d or automatic (stack-allocated).  I haven't
tried a static array, that's next on my list.  I'll try to get to the
bottom of this eventually.

>   Here's the patch, against current CVS.  I'll let Igor supply the
> ChangeLog entry, since it was his fix.

Can't for a while.  Can you do me a favor and submit this as a fix, if you
have a copyright assignment for Cygwin?  If it makes you feel better, feel
free to mention me in the ChangeLog as well.

FWIW, there's another buglet (redundant piece of code, actually): "type"
is never used, so doesn't need to be passed in.  Might as well fix that
(just pass NULL), and the typo in the file name (HKEY_PERFO*R*MANCE_DATA),
in this patch.
	Igor

> Index: winsup/cygwin/fhandler_registry.cc
> ===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/fhandler_registry.cc,v
> retrieving revision 1.24
> diff -p -u -r1.24 fhandler_registry.cc
> --- winsup/cygwin/fhandler_registry.cc  9 Feb 2004 04:04:23 -0000       1.24
> +++ winsup/cygwin/fhandler_registry.cc  14 Jul 2004 16:47:53 -0000
> @@ -575,6 +575,7 @@ fhandler_registry::fill_filebuf ()
>         {
>           bufalloc += 1000;
>           filebuf = (char *) realloc (filebuf, bufalloc);
> +          size = bufalloc;
>           error = RegQueryValueEx (handle, value_name, NULL, &type,
>                                    (BYTE *) filebuf, &size);
>           if (error != ERROR_SUCCESS && error != ERROR_MORE_DATA)

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

RE: [OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Dave Korn
> Sent: 14 July 2004 18:26

>   Well, the thread's more-or-less over now, I would have thought.

  Heh.  It occurs to me to correct that typo while we're at it.  Should have
done that first time round.

dk@mace /usr/build/src/winsup/cygwin> cvs -q -z9 diff -pu
Index: fhandler_registry.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_registry.cc,v
retrieving revision 1.24
diff -p -u -r1.24 fhandler_registry.cc
--- fhandler_registry.cc        9 Feb 2004 04:04:23 -0000       1.24
+++ fhandler_registry.cc        14 Jul 2004 18:27:49 -0000
@@ -48,7 +48,7 @@ static const char *registry_listing[] =
   "HKEY_LOCAL_MACHINE",
   "HKEY_USERS",
   "HKEY_DYN_DATA",             // 95/98/Me
-  "HKEY_PERFOMANCE_DATA",      // NT/2000/XP
+  "HKEY_PERFORMANCE_DATA",     // NT/2000/XP
   NULL
 };

@@ -575,6 +575,7 @@ fhandler_registry::fill_filebuf ()
        {
          bufalloc += 1000;
          filebuf = (char *) realloc (filebuf, bufalloc);
+          size = bufalloc;
          error = RegQueryValueEx (handle, value_name, NULL, &type,
                                   (BYTE *) filebuf, &size);
          if (error != ERROR_SUCCESS && error != ERROR_MORE_DATA)



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Wed, 14 Jul 2004, Igor Pechtchanski wrote:

> On Wed, 14 Jul 2004, Dave Korn wrote:
>
> [snip]
> > In particular, the fact that you see a SEGV the second time round -
> > which is what my analysis above demonstrates should happen if the size
> > variable is NOT reinited each time round the loop - makes me think you
> > didn't actually test the right code.  You better double-check.
>
> Triple-checked.  Your analysis would have been correct for any key but
> HKEY_PERFORMANCE_DATA.

Forgot to mention: if I allocate a large enough buffer (~128k), I get a
SEGV on the first iteration.
	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/

Developer's list archive policy - was Re: [OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Larry Hall]

At 01:25 PM 7/14/2004, you wrote:

>  Still, I've sent in a subscription request anyway  [Note Cc!].  I've never
>paid much attention to that list before.  I notice that even the list
>archive is closed if you aren't subbed - surely that's a bit WJM?  I can
>understand having subscribers-only posting rules, and I can understand
>wanting to have only serious developers posting there, but I don't see why
>it shouldn't be viewable and searchable for everyone else.


It used to be but we got too many people looking at the archives and then
posting follow-ups to the cygwin list, etc. so Chris closed it down.  It's
been closed down now for quite a while. 


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Dave Korn]

> -----Original Message-----
> From: Igor Pechtchanski  
> Sent: 14 July 2004 19:30

> >   I concur; that is bad code.  The variable unambiguously needs
> > initialising, and since RegQueryValueEx damages it, it needs to be
> > re-set each time round the loop.
> 
> Not quite true.  Turns out RegQueryValueEx doesn't touch the 
> value of size
> if the buffer is too small (for HKEY_PERFORMANCE_DATA).  So 
> size stayed at
> 0.

  A closer reading of the docs reveals you are indeed correct.

> Hmm, did you verify this in gdb?  Mine showed size=0 until I added the
> assignment.

  Nope, I didn't.  I got as far as verifying that setting the size variable
manually just before the call to RegQueryValueEx fixed the bug.
Unfortunately insight wasn't working well enough to print the values of any
variables, so I was ploughing through the assembler code :(
 
[It turns out that the problem is that insight doesn't recognize when a
variable in a source statement is a member variable with an implied
'this->', so right-clicking on it and trying to add it to the watch window
doesn't work.  By the time I had figured this out, however, I had found the
fix working for me.]

> > > However, the fix is not as simple as inserting a "size = 
> bufalloc;"
> > > just before the RegQueryValueEx.  When I do that, I get a 
> SIGSEGV in
> > > the guts of iasperf.dll, which I have yet to track down.  

  That'll be the performance monitor dll, then, presumably in some routine
where it's gathered some data from somewhere and is writing it to your
buffer.  Presumably it's writing the data to an invalid address.  Or there's
a discrepancy somehow between the actual allocated buffer size and the value
you end up passing in *size, and the dll is writing past the end of the
buffer.

> This happens
> > > on the second iteration, FWIW, with buffer increment of 1000.
> >
> >   That's funny.  It WFMHRN.
> 
> "Works for me here right now"?

  Yep!
 
> > Are you completely sure that you put that line in the right place?
> 
> Yes.

  'k.

> > Are you sure you remembered to rebuild the dll after 
> editing the source?
> 
> Yes.

  'k.

> > Are you sure you tested the new version of the dll rather 
> than some old
> > one?
> 
> Yes.

  'k.  That covers most of the _obvious_ possibilities.

> > I know some of these things sound daft, but since the fix is a)
> > obviously correct, and b) tested and working, I suspect 
> that you made
> > some little error in the procedure that invalidated your test.
> 
> ...or we have some differences in user permissions, operating systems,
> environments, setup, etc, etc, etc.  In any case, the above does *NOT*
> work for me.

  How bizarre.  Did you verify in gdb that the variable *was* being
correctly set?

> > You wouldn't believe how often I ALT+TAB to another window and type
> > "make all" only to realise I haven't saved all the changed 
> files that I
> > have in my editor window, only some of them!
> 
> I'm reasonably sure I've rebuilt everything from scratch (I even did a
> "make clean" - ouch).

  Yep, although that wouldn't help if you'd not pressed Ctrl+S in your
editor yet....

> > In particular, the fact that you see a SEGV the second time round -
> > which is what my analysis above demonstrates should happen 
> if the size
> > variable is NOT reinited each time round the loop - makes 
> me think you
> > didn't actually test the right code.  You better double-check.
> 
> Triple-checked.  Your analysis would have been correct for any key but
> HKEY_PERFORMANCE_DATA.

  Yep, point taken.

> I believe you.  It just doesn't work for me. :-(  In fact, 
> I'm getting a
> segfault whenever the RegQueryValueEx call attempts to write 
> anything to
> a buffer, whether realloc()'d or automatic (stack-allocated). 
>  I haven't
> tried a static array, that's next on my list.  I'll try to get to the
> bottom of this eventually.

  How bizarre.  It might be worth running the whole thing under windbg,
which will give you symbols for the windoze dlls.  Then you'll know what
routine you're in in iasperf.dll.

> Can't for a while.  Can you do me a favor and submit this as 
> a fix, if you
> have a copyright assignment for Cygwin?  

  Not yet, unfortunately.

> If it makes you feel 
> better, feel
> free to mention me in the ChangeLog as well.

  Will do!

> FWIW, there's another buglet (redundant piece of code, 
> actually): "type"
> is never used, so doesn't need to be passed in.  Might as 
> well fix that
> (just pass NULL), and the typo in the file name 
> (HKEY_PERFO*R*MANCE_DATA),
> in this patch.

  Heh.  Patches that cross in the mail.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Corinna Vinschen]

On Jul 14 14:29, Igor Pechtchanski wrote:
> Since Dave is not subscribed to cygwin-developers anyway, I'll continue
> this here.  More below.

Ok.  That's why I wrote "mildly OT".

> Can't for a while.  Can you do me a favor and submit this as a fix, if you
> have a copyright assignment for Cygwin?  If it makes you feel better, feel
> free to mention me in the ChangeLog as well.

David has no copyright assignment on file so far.  But that doesn't matter
since the below is definitely a "trivial" patch.  Just a ChangeLog entry,
please.

Corinna


> > Index: winsup/cygwin/fhandler_registry.cc
> > ===================================================================
> > RCS file: /cvs/src/src/winsup/cygwin/fhandler_registry.cc,v
> > retrieving revision 1.24
> > diff -p -u -r1.24 fhandler_registry.cc
> > --- winsup/cygwin/fhandler_registry.cc  9 Feb 2004 04:04:23 -0000       1.24
> > +++ winsup/cygwin/fhandler_registry.cc  14 Jul 2004 16:47:53 -0000
> > @@ -575,6 +575,7 @@ fhandler_registry::fill_filebuf ()
> >         {
> >           bufalloc += 1000;
> >           filebuf = (char *) realloc (filebuf, bufalloc);
> > +          size = bufalloc;
> >           error = RegQueryValueEx (handle, value_name, NULL, &type,
> >                                    (BYTE *) filebuf, &size);
> >           if (error != ERROR_SUCCESS && error != ERROR_MORE_DATA)

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Co-Project Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Wed, 14 Jul 2004, Dave Korn wrote:

> [some comments snipped below]
> > -----Original Message-----
> > From: Igor Pechtchanski
> > Sent: 14 July 2004 19:30
>
> > > > However, the fix is not as simple as inserting a "size =
> > > > bufalloc;" just before the RegQueryValueEx.  When I do that, I get
> > > > a SIGSEGV in the guts of iasperf.dll, which I have yet to track
> > > > down.
>
>   That'll be the performance monitor dll, then, presumably in some
> routine where it's gathered some data from somewhere and is writing it
> to your buffer.  Presumably it's writing the data to an invalid address.
> Or there's a discrepancy somehow between the actual allocated buffer
> size and the value you end up passing in *size, and the dll is writing
> past the end of the buffer.

That's what I figured.  What's suspicious is that this happens for three
completely different ranges of addresses -- automatic, dynamic (using
malloc), and static (yes, that too).  There must be something I'm doing
wrong here.

> > ...or we have some differences in user permissions, operating systems,
> > environments, setup, etc, etc, etc.  In any case, the above does *NOT*
> > work for me.
>
>   How bizarre.  Did you verify in gdb that the variable *was* being
> correctly set?

Yep.  It gets set correctly, but as soon as the buffer is large enough
and RegQueryValueEx attempts to write to it, it bails out.

> > I'm reasonably sure I've rebuilt everything from scratch (I even did a
> > "make clean" - ouch).
>
>   Yep, although that wouldn't help if you'd not pressed Ctrl+S in your
> editor yet....

I use vi. :-p  I've quit it, which is usually a good indication that the
file is saved. :-D

> > I believe you.  It just doesn't work for me. :-( In fact, I'm getting
> > a segfault whenever the RegQueryValueEx call attempts to write
> > anything to a buffer, whether realloc()'d or automatic
> > (stack-allocated).  I haven't tried a static array, that's next on my
> > list.  I'll try to get to the bottom of this eventually.
>
>   How bizarre.  It might be worth running the whole thing under windbg,
> which will give you symbols for the windoze dlls.  Then you'll know what
> routine you're in in iasperf.dll.

I don't have windbg installed...  If I can't figure things out, I'll do
that eventually.

> > Can't for a while.  Can you do me a favor and submit this as a fix, if
> > you have a copyright assignment for Cygwin?
>
>   Not yet, unfortunately.

Well, as Corinna said, this qualifies as trivial, so you don't need one.

> > If it makes you feel better, feel free to mention me in the ChangeLog
> > as well.
>
>   Will do!
>
> > FWIW, there's another buglet (redundant piece of code, actually):
> > "type" is never used, so doesn't need to be passed in.  Might as well
> > fix that (just pass NULL), and the typo in the file name
> > (HKEY_PERFO*R*MANCE_DATA), in this patch.
>
>   Heh.  Patches that cross in the mail.

I don't believe you fixed the "&type" thing in yours...

On Wed, 14 Jul 2004, Corinna Vinschen wrote:

> On Jul 14 14:29, Igor Pechtchanski wrote:
>
> > Can't for a while.  Can you do me a favor and submit this as a fix, if you
> > have a copyright assignment for Cygwin?  If it makes you feel better, feel
> > free to mention me in the ChangeLog as well.
>
> David has no copyright assignment on file so far.  But that doesn't matter
> since the below is definitely a "trivial" patch.  Just a ChangeLog entry,
> please.

Dave, can you please send in an updated patch and a ChangeLog entry (with
your name as the contributor, for various legal reasons)?
	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/

Re: [OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Christopher Faylor]

On Wed, Jul 14, 2004 at 07:28:19PM +0100, Dave Korn wrote:
>>-----Original Message-----
>>From: cygwin-owner On Behalf Of Dave Korn
>>Sent: 14 July 2004 18:26
>
>>Well, the thread's more-or-less over now, I would have thought.
>
>Heh.  It occurs to me to correct that typo while we're at it.  Should have
>done that first time round.
>
>dk@mace /usr/build/src/winsup/cygwin> cvs -q -z9 diff -pu
>Index: fhandler_registry.cc

Since this is a relatively simple patch and I took the libiberty of creating
a ChangeLog and checking it in.

Thanks.

cgf

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Chris January]

> However, the fix is not as simple as inserting a "size = 
> bufalloc;" just before the RegQueryValueEx.  When I do that, 
> I get a SIGSEGV in the guts of iasperf.dll, which I have yet 
> to track down.  This happens on the second iteration, FWIW, 
> with buffer increment of 1000.  I'm going to investigate some 
> more, but I'd say that with the above bug, this key was never 
> tested, so I have no idea what's going on.  Hopefully Chris
> (January) can use this to help him track down the problem.

I'm back from my honeymoon (!) and I've just been catching up on this
thread. Are you still seeing the segfault Igor? If so I'll try to track
it down if I have any spare time.

As you can probably tell I never tested the HKEY_PERFORMANCE_DATA key.
Increasing the buffer size in increments is of course boilerplate code
but I managed to cod it up regardless. Sigh.

Chris January


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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Mon, 19 Jul 2004, Chris January wrote:

> > However, the fix is not as simple as inserting a "size =
> > bufalloc;" just before the RegQueryValueEx.  When I do that,
> > I get a SIGSEGV in the guts of iasperf.dll, which I have yet
> > to track down.  This happens on the second iteration, FWIW,
> > with buffer increment of 1000.  I'm going to investigate some
> > more, but I'd say that with the above bug, this key was never
> > tested, so I have no idea what's going on.  Hopefully Chris
> > (January) can use this to help him track down the problem.
>
> I'm back from my honeymoon (!)

Great, hope you enjoyed it...

> and I've just been catching up on this thread.

...and I'm sure you didn't enjoy this. :-)

> Are you still seeing the segfault Igor? If so I'll try to track it down
> if I have any spare time.

Yes, I'm still seeing the segfault in the latest snapshot, but only when
run under gdb or strace.  Here are some sample tests:

$ cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
cat: /proc/registry/HKEY_PERFORMANCE_DATA/@: No such file or directory
$ # no segfault
$ strace -o cat_HKPD.strace cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
2262669 [main] cat 2400 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
2264445 [main] cat 2400 open_stackdumpfile: Dumping stack trace to cat.exe.stackdump
$

I can also send you cat_HKPD.strace, but it's not very informative.  Let
me know if you can't reproduce this and need me to debug this locally.
FWIW, I have a working piece of Win32 code that does read this key
correctly (essentially a stripped down MS example).  Let me know if you
need it.

> As you can probably tell I never tested the HKEY_PERFORMANCE_DATA key.

Yep, so I surmised.

> Increasing the buffer size in increments is of course boilerplate code
> but I managed to cod it up regardless. Sigh.
>
> Chris January

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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Robert Pendell]

I have no clue if anyone thought to bring this up but how about
telling us what combination shell and console that you use.

Example:
I use rxvt and bash combination (rxvt is console / bash is shell) and
there are no problems -- it just echos what I typed if it can't access
what I want.  If I start up sh though within that session and run the
same command 'cat' will show the same problem as what started this
thread from the start.

On Mon, 19 Jul 2004 14:36:40 -0400 (EDT), Igor Pechtchanski
<pechtcha@cs.nyu.edu> wrote:
> On Mon, 19 Jul 2004, Chris January wrote:
> 
> > > However, the fix is not as simple as inserting a "size =
> > > bufalloc;" just before the RegQueryValueEx.  When I do that,
> > > I get a SIGSEGV in the guts of iasperf.dll, which I have yet
> > > to track down.  This happens on the second iteration, FWIW,
> > > with buffer increment of 1000.  I'm going to investigate some
> > > more, but I'd say that with the above bug, this key was never
> > > tested, so I have no idea what's going on.  Hopefully Chris
> > > (January) can use this to help him track down the problem.
> >
> > I'm back from my honeymoon (!)
> 
> Great, hope you enjoyed it...
> 
> > and I've just been catching up on this thread.
> 
> ...and I'm sure you didn't enjoy this. :-)
> 
> > Are you still seeing the segfault Igor? If so I'll try to track it down
> > if I have any spare time.
> 
> Yes, I'm still seeing the segfault in the latest snapshot, but only when
> run under gdb or strace.  Here are some sample tests:
> 
> $ cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> cat: /proc/registry/HKEY_PERFORMANCE_DATA/@: No such file or directory
> $ # no segfault
> $ strace -o cat_HKPD.strace cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> 2262669 [main] cat 2400 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
> 2264445 [main] cat 2400 open_stackdumpfile: Dumping stack trace to cat.exe.stackdump
> $
> 
> I can also send you cat_HKPD.strace, but it's not very informative.  Let
> me know if you can't reproduce this and need me to debug this locally.
> FWIW, I have a working piece of Win32 code that does read this key
> correctly (essentially a stripped down MS example).  Let me know if you
> need it.
> 
> > As you can probably tell I never tested the HKEY_PERFORMANCE_DATA key.
> 
> Yep, so I surmised.
> 
> > Increasing the buffer size in increments is of course boilerplate code
> > but I managed to cod it up regardless. Sigh.
> >
> > Chris January
> 
> HTH,
> 
> 
>         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/
> 
> 


-- 
Robert Pendell
shinji257@gmail.com

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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

I don't think it matters.  I get the same exact results with both sh and
bash in any one of the cmd window, xterm, or rxvt.  FWIW, the output below
was with cmd/bash.  You *are* trying the latest snapshot, right?

I'm not sure I understand what "there are no problems -- it just echos
what I typed if it can't access what I want" means, either.  The point is
that it's *supposed* to be able to access that registry key.
	Igor
P.S. <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.

On Mon, 19 Jul 2004, Robert Pendell wrote:

> I have no clue if anyone thought to bring this up but how about
> telling us what combination shell and console that you use.
>
> Example:
> I use rxvt and bash combination (rxvt is console / bash is shell) and
> there are no problems -- it just echos what I typed if it can't access
> what I want.  If I start up sh though within that session and run the
> same command 'cat' will show the same problem as what started this
> thread from the start.
>
> On Mon, 19 Jul 2004 14:36:40 -0400 (EDT), Igor Pechtchanski <pechtcha@XX.XXX.XXX> wrote:
> > On Mon, 19 Jul 2004, Chris January wrote:
> >
> > > > However, the fix is not as simple as inserting a "size =
> > > > bufalloc;" just before the RegQueryValueEx.  When I do that,
> > > > I get a SIGSEGV in the guts of iasperf.dll, which I have yet
> > > > to track down.  This happens on the second iteration, FWIW,
> > > > with buffer increment of 1000.  I'm going to investigate some
> > > > more, but I'd say that with the above bug, this key was never
> > > > tested, so I have no idea what's going on.  Hopefully Chris
> > > > (January) can use this to help him track down the problem.
> > >
> > > I'm back from my honeymoon (!)
> >
> > Great, hope you enjoyed it...
> >
> > > and I've just been catching up on this thread.
> >
> > ...and I'm sure you didn't enjoy this. :-)
> >
> > > Are you still seeing the segfault Igor? If so I'll try to track it down
> > > if I have any spare time.
> >
> > Yes, I'm still seeing the segfault in the latest snapshot, but only when
> > run under gdb or strace.  Here are some sample tests:
> >
> > $ cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> > cat: /proc/registry/HKEY_PERFORMANCE_DATA/@: No such file or directory
> > $ # no segfault
> > $ strace -o cat_HKPD.strace cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> > 2262669 [main] cat 2400 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
> > 2264445 [main] cat 2400 open_stackdumpfile: Dumping stack trace to cat.exe.stackdump
> > $
> >
> > I can also send you cat_HKPD.strace, but it's not very informative.  Let
> > me know if you can't reproduce this and need me to debug this locally.
> > FWIW, I have a working piece of Win32 code that does read this key
> > correctly (essentially a stripped down MS example).  Let me know if you
> > need it.
> >
> > > As you can probably tell I never tested the HKEY_PERFORMANCE_DATA key.
> >
> > Yep, so I surmised.
> >
> > > Increasing the buffer size in increments is of course boilerplate code
> > > but I managed to cod it up regardless. Sigh.
> > >
> > > Chris January

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

Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Robert Pendell]

See below for responses

On Mon, 19 Jul 2004 19:13:32 -0400 (EDT), Igor Pechtchanski wrote:
> I don't think it matters.  I get the same exact results with both sh and
> bash in any one of the cmd window, xterm, or rxvt.  FWIW, the output below
> was with cmd/bash.  You *are* trying the latest snapshot, right?

I havn't been trying the latest snapshot as I wasn't aware that anyone
was.  I will probably work into getting it tomorrow when I actually
get a chance to.

> 
> I'm not sure I understand what "there are no problems -- it just echos
> what I typed if it can't access what I want" means, either.  The point is
> that it's *supposed* to be able to access that registry key.

IC.  Well I was doing the scenario wrong anyways.  I had typed it and
it just echoed it then I copied and pasted it and it got stuck
accessing the key.  Then I compared what I typed to what I pasted and
there was an 'r' in Performance where there shouldn't be.  Meaning
Performance where I typed it should of been Perfomance.  Note the
missing 2nd 'r'.
*embaressed*

>         Igor
> P.S. <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.

Damn.  Do I keep forgetting to remove the email address sometimes. 
GMail does not have the option yet and I have put in a request.  We
will see if they implement it but it is unlikely.

-- 
Robert Pendell
shinji257@gmail.com

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Chris January]

> Yes, I'm still seeing the segfault in the latest snapshot, 
> but only when run under gdb or strace.  Here are some sample tests:
> 
> $ cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> cat: /proc/registry/HKEY_PERFORMANCE_DATA/@: No such file or 
> directory $ # no segfault $ strace -o cat_HKPD.strace cat 
> /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out 2262669 
> [main] cat 2400 handle_exceptions: Exception: 
> STATUS_ACCESS_VIOLATION 2264445 [main] cat 2400 
> open_stackdumpfile: Dumping stack trace to cat.exe.stackdump $

I can't reproduce this with CVS. Can you?

Chris


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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Igor Pechtchanski]

On Mon, 26 Jul 2004, Chris January wrote:

> > Yes, I'm still seeing the segfault in the latest snapshot,
> > but only when run under gdb or strace.  Here are some sample tests:
> >
> > $ cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> > cat: /proc/registry/HKEY_PERFORMANCE_DATA/@: No such file or directory
> > $ # no segfault
> > $ strace -o cat_HKPD.strace cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> > 2262669 [main] cat 2400 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
> > 2264445 [main] cat 2400 open_stackdumpfile: Dumping stack trace to cat.exe.stackdump
> > $
>
> I can't reproduce this with CVS. Can you?
> Chris

Yes, I can.  I just compiled ([1]) the latest CVS cygwin0.dll (as of
today, 14:31 UTC), then tested with the new DLL ([2]).  I get the same
exact errors (including the stackdump).  Interestingly enough, I had other
unexplained exceptions with this test approach, so I'd appreciate if
anyone points out what's wrong with it.
	Igor

[1] "cd build/i686-pc-cygwin/winsup/cygwin && make clean all"
[2] "cd test && cygstart ./bash.exe" then run the above commands from
    the prompt, where "test" is a directory containing executables
    binary-edited to use cygwin0.dll instead of cygwin1.dll, confirmed by
    cygcheck.  Note that my build was configured with --enable-debugging.
-- 
				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!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs

[Chris January]

> > > Yes, I'm still seeing the segfault in the latest 
> snapshot, but only 
> > > when run under gdb or strace.  Here are some sample tests:
> > >
> > > $ cat /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out
> > > cat: /proc/registry/HKEY_PERFORMANCE_DATA/@: No such file or 
> > > directory $ # no segfault $ strace -o cat_HKPD.strace cat 
> > > /proc/registry/HKEY_PERFORMANCE_DATA/\@ > e.out 2262669 
> [main] cat 
> > > 2400 handle_exceptions: Exception: 
> STATUS_ACCESS_VIOLATION 2264445 
> > > [main] cat 2400 open_stackdumpfile: Dumping stack trace to 
> > > cat.exe.stackdump $
> >
> > I can't reproduce this with CVS. Can you?
> > Chris
> 
> Yes, I can.  I just compiled ([1]) the latest CVS cygwin0.dll 
> (as of today, 14:31 UTC), then tested with the new DLL ([2]). 
>  I get the same exact errors (including the stackdump).  
> Interestingly enough, I had other unexplained exceptions with 
> this test approach, so I'd appreciate if anyone points out 
> what's wrong with it.

Could you send me a copy of the stackdump and the strace output by
private mail please?

Chris


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