On Friday 10 March 2006 04:20, Magnus Hagander wrote:
> > > Is it possible to get a stack trace from the stuck process?
> >
> > I dunno
> >
> > > if you've got anything gdb-equivalent under Windows, but that's the
> > > first thing I'd be interested in ...
> >
> > Here ya go:
> >
> > http://www.devisser-siderius.com/stack1.jpg
> > http://www.devisser-siderius.com/stack2.jpg
> > http://www.devisser-siderius.com/stack3.jpg
> >
> > There are three threads in the process. I guess thread 1
> > (stack1.jpg) is the most interesting.
> >
> > I also noted that cranking up concurrency in my app
> > reproduces the problem in about 4 minutes ;-)
>
Just reproduced again.
> Actually, stack2 looks very interesting. Does it "stay stuck" in
> pg_queue_signal? That's really not supposed to happen.
Yes it does.
>
> Also, can you confirm that stack1 actually *stops* in
> pgwin32_waitforsinglesocket? Or does it go out and come back? ;-)
>
> (A good signal of this is to check the cswitch delta. If it stays at zero,
> then it's stuck. If it shows any values, that means it's actuall going out
> and coming back)
I only see CSwitch change once I click OK on the thread window. Once I do
that, it goes up to 3 and back to blank again. The 'context switches' counter
does not increase like it does for other processes (like e.g. process
explorer itself).
Another thing which may or may not be of interest: Nothing is listed in the
'TCP/IP' tab for the stuck process. I would have expected to see at least the
socket of the client connection there??
>
> And finally, is this 8.0 or 8.1? There have been some significant changes
> in the handling of the signals between the two...
This is 8.1.3 on Windows 2003 Server. Also reproduced on 8.1.0 and 8.1.1 (also
on 2K3).
>
> //Magnus
jan
--
--------------------------------------------------------------
Jan de Visser jdevisser@digitalfairway.com
Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------
