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


On Tue, 13 Jul 2004, Igor Pechtchanski wrote:

> On Tue, 13 Jul 2004, Dave Korn wrote:
>
> [snip]
> > I didn't get around to trying the actual cat instruction he quoted.
> > I'll try it now:
> >
> > dk@mace ~> cat /proc/registry/HKEY_PERFOMANCE_DATA
> > Segmentation fault (core dumped)
> > dk@mace ~> cat /proc/registry/HKEY_PERFOMANCE_DATA/@
> >
> >   And then it hangs, as described.  Takes (up to) 100%cpu, as well.  However
> > I find that unlike Reini, I can kill it easily enough:
> >[snip]
> >   Well, I get the segfaults *and* Reini's bug.  Guess I'm just lucky!
>
> You will have to debug the segfaults yourself.  As for the source or the
> "Reini bug", this piece of code from fhandler_registry.cc looks
> suspicious, in particular, the line marked with "==>" (line 576):
>
>   else
>     {
>       bufalloc = 0;
>       do
>         {
> ==>       bufalloc += 1000;
>           filebuf = (char *) realloc (filebuf, bufalloc);
>           error = RegQueryValueEx (handle, value_name, NULL, &type,
>                                    (BYTE *) filebuf, &size);
>           if (error != ERROR_SUCCESS && error != ERROR_MORE_DATA)
>             {
>               if (error != ERROR_FILE_NOT_FOUND)
>                 {
>                   seterrno_from_win_error (__FILE__, __LINE__, error);
>                   return true;
>                 }
>               goto value_not_found;
>             }
>         }
>       while (error == ERROR_MORE_DATA);
>       filesize = size;
>     }
>
> I have a theory that the performance data may be added in chunks larger
> than 1000 bytes, so the fhandler just can't keep up with the amount of
> data, and loops indefinitely.  Since you intend to build the DLL from CVS,
> you're probably in the best position to check whether this theory is true
> (by either just upping the increment amount to something like 5000, or
> even doubling the buffer size on each iteration).  If you can't do this,
> I'll get to building the DLL tonight and do the above check.
> 	Igor

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

However, the fix is not as simple as inserting a "size = bufalloc;" just
before the RegQueryValueEx.  When I do that, I get a SIGSEGV in the guts
of iasperf.dll, which I have yet to track down.  This happens on the
second iteration, FWIW, with buffer increment of 1000.  I'm going to
investigate some more, but I'd say that with the above bug, this key was
never tested, so I have no idea what's going on.  Hopefully Chris
(January) can use this to help him track down the problem.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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