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
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
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
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
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
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
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
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
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
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
-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
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
-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
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
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
-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]
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
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
-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
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
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
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
cat /proc/registry/HKEY_PERFOMANCE_DATA/@
hangs forever.
Win2K (no win98 OS)
Shouldn't HKEY_PERFOMANCE_DATA be disabled on NT systems, or does it work?
This cat has pid 560:
$ cat /proc/560/status
Name: cat
State: R (runnable)
Tgid: 560
Pid:560
PPid: 1956
Uid:1000 1000 1000 1000
Gid
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
-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
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
-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?
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.
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
] ~ 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
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
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
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
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
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
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);
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
37 matches
Mail list logo