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/

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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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


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

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
[EMAIL PROTECTED]

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

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 <[EMAIL PROTECTED]> 
> 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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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
<[EMAIL PROTECTED]> 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/
>   |\  _,,,---,,_[EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
>  |,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
[EMAIL PROTECTED]

--
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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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

[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: [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.
>
>[EMAIL PROTECTED] /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

[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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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

[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 -   1.24
> > +++ winsup/cygwin/fhandler_registry.cc  14 Jul 2004 16:47:53 -
> > @@ -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:[EMAIL PROTECTED]
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: 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/

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

[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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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.

[EMAIL PROTECTED] /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.cc9 Feb 2004 04:04:23 -   1.24
+++ fhandler_registry.cc14 Jul 2004 18:27:49 -
@@ -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]

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
():

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

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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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/

[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

[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:[EMAIL PROTECTED]
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 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 wy 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:

[EMAIL PROTECTED] ~/reg-test> ls -la
total 78
drwxr-xr-x+   2 dk   Domain U0 Jul 14 17:44 .
drwxrwxrwx+   6 dk   Domain U0 Jul 14 17:43 ..
-rw-r--r--1 dk   Domain U79264 Jul 14 17:44 test1.dat
[EMAIL PROTECTED] ~/reg-test> cat /proc/registry/HKEY_PERFOMANCE_DATA/@ >test2.dat
[EMAIL PROTECTED] ~/reg-test> cat /proc/registry/HKEY_PERFOMANCE_DATA/@ >test3.dat
[EMAIL PROTECTED] ~/reg-test> cat /proc/registry/HKEY_PERFOMANCE_DATA/@ >test4.dat
[EMAIL PROTECTED] ~/reg-test> ls -la
total 312
drwxr-xr-x+   2 dk   Domain U0 Jul 14 17:44 .
drwxrwxrwx+   6 dk   Domain U0 Jul 14 17:43 ..
-rw-r--r--1 dk   Domain U79264 Jul 14 17:44 test1.dat
-rw-r--r--1 dk   Domain U79264 Jul 14 17:44 test2.dat
-rw-r--r--1 dk   Domain U79264 Jul 14 17:44 test3.dat
-rw-r--r--1 dk   Domain U79264 Jul 14 17:44 test4.dat
[EMAIL PROTECTED] ~/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 -   1.24
+++ winsup/cygwin/fhandler_registry.cc  14 Jul 2004 16:47:53 -
@@ -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, 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
> > ():
> > [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
>PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
>   1432   11432   14320 1000 11:47:24 /usr/bin/bash
>6361432 636   17240 1000 11:47:37 /usr/bin/cat
>   1732   11732   17321 1000 11:49:10 /usr/bin/bash
>   177217321772   17841 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 .  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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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
():
...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
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 1432   11432   14320 1000 11:47:24 /usr/bin/bash
  6361432 636   17240 1000 11:47:37 /usr/bin/cat
 1732   11732   17321 1000 11:49:10 /usr/bin/bash
 177217321772   17841 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 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:
> >
> > [EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA
> > Segmentation fault (core dumped)
> > [EMAIL PROTECTED] ~> 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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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 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, 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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Ne.e..d m...or..e co...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

[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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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 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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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, 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:
> > >
> > > [EMAIL PROTECTED] /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
():

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:
>
> [EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA
> Segmentation fault (core dumped)
> [EMAIL PROTECTED] ~> 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]
> [EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
>   [Hangs.  Meanwhile in window 2:]
> [EMAIL PROTECTED] ~> ps
>   PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
> [snip]
>  259638842596   1672  con 11165 16:46:07 /usr/bin/cat
>  338040083380   2280  con 11165 16:46:26 /usr/bin/ps
> [EMAIL PROTECTED] ~> kill 2596
> [EMAIL PROTECTED] ~>
> [And back in window 1:]
> [EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
> Terminated
> [EMAIL PROTECTED] ~>
>
> > 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;

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:
> >
> > [EMAIL PROTECTED] /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:

[EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA
Segmentation fault (core dumped)
[EMAIL PROTECTED] ~> 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]
[EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
  [Hangs.  Meanwhile in window 2:]
[EMAIL PROTECTED] ~> ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
I2464   12464   2464  con 11165 11:44:15 /usr/bin/bash
 3908   13908   3908  con 11165 16:03:39 /usr/bin/bash
  7803908 780   3628  con 11165 16:34:03 /usr/bin/make
I10283908 780   1076  con 11165 16:34:03 /usr/bin/tee
 3884   13884   3884  con 11165 16:45:18 /usr/bin/bash
 4008   14008   4008  con 11165 16:45:20 /usr/bin/bash
 2736 780 780   2772  con 11165 16:45:25 /usr/bin/sh
 31322736 780   2340  con 11165 16:45:25 /usr/bin/make
  2443132 780   2440  con 11165 16:45:25 /usr/bin/sh
 3720 244 780180  con 11165 16:45:25 /usr/bin/make
 16923720 780   2172  con 11165 16:46:06 /usr/bin/sh
 23841692 780   2936  con 11165 16:46:06 /usr/bin/gcc
 34122384 780   3412  con 11165 16:46:07 /usr/bin/gcc
 259638842596   1672  con 11165 16:46:07 /usr/bin/cat
 338040083380   2280  con 11165 16:46:26 /usr/bin/ps
[EMAIL PROTECTED] ~> kill 2596
[EMAIL PROTECTED] ~>
[And back in window 1:]
[EMAIL PROTECTED] ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
Terminated
[EMAIL PROTECTED] ~>

> 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: 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:
>
> [EMAIL PROTECTED] /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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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 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:

[EMAIL PROTECTED] /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

[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:
> 
> [EMAIL PROTECTED] ~> cd /proc/registry/
> [EMAIL PROTECTED] /proc/registry> ls
> HKEY_CLASSES_ROOTHKEY_CURRENT_USER  HKEY_LOCAL_MACHINEHKEY_USERS
> HKEY_CURRENT_CONFIG  HKEY_DYN_DATA  HKEY_PERFOMANCE_DATA
> [EMAIL PROTECTED] /proc/registry> ls -la
> Segmentation fault (core dumped)
> [EMAIL PROTECTED] /proc/registry>
> 
> next I type 'ls'   to get
> 
> [EMAIL PROTECTED] /proc/registry> ls HKEY_
> 
> then I press P  and the bash window vanishes !!
> 
> 
> And check this too:
> 
> [EMAIL PROTECTED] /proc/registry> getfacl HKEY_PERFOMANCE_DATA
> Segmentation fault (core dumped)
> [EMAIL PROTECTED] /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)
> [EMAIL PROTECTED] /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:[EMAIL PROTECTED]
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 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
> ():

[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:

[EMAIL PROTECTED] ~> cd /proc/registry/
[EMAIL PROTECTED] /proc/registry> ls
HKEY_CLASSES_ROOTHKEY_CURRENT_USER  HKEY_LOCAL_MACHINEHKEY_USERS
HKEY_CURRENT_CONFIG  HKEY_DYN_DATA  HKEY_PERFOMANCE_DATA
[EMAIL PROTECTED] /proc/registry> ls -la
Segmentation fault (core dumped)
[EMAIL PROTECTED] /proc/registry>

next I type 'ls'   to get

[EMAIL PROTECTED] /proc/registry> ls HKEY_

then I press P  and the bash window vanishes !!


And check this too:

[EMAIL PROTECTED] /proc/registry> getfacl HKEY_PERFOMANCE_DATA
Segmentation fault (core dumped)
[EMAIL PROTECTED] /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)
[EMAIL PROTECTED] /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

[Igor Pechtchanski]

On Tue, 13 Jul 2004, Reini Urban wrote:

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

According to MSDN
():

...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/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,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/