RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
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
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
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
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 [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
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
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
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
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 [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
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 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
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 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 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/ |\ _,,,---,,_[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
-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
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/
[OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
-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
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/
RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
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 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 buglet (redundant piece of code, actually): type is never used, so
RE: [OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
-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
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/
Developer's list archive policy - was Re: [OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
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
-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
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
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: [OT] RE: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
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
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/ |\ _,,,---,,_[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
-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: [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' space tab to get [EMAIL PROTECTED] /proc/registry ls HKEY_ then I press P tab 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
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' space tab to get [EMAIL PROTECTED] /proc/registry ls HKEY_ then I press P tab 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
-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
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
-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
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
(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:
[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;
do
{
== bufalloc += 1000;
filebuf = (char *) realloc (filebuf, bufalloc);
error = RegQueryValueEx (handle, value_name, NULL, type,
Re: cat /proc/registry/HKEY_PERFOMANCE_DATA/@ hangs
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
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
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
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
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
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
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/
