This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]