| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2626.1 | | DECWIN::JMSYNGE | James M Synge, VMS Development | Wed Apr 18 1990 14:07 | 16 |
| 2dba104 is the code for the message
"%DECW-F-BUFFERTIMEOUT, buffer wait timed out"
It means that your application wasn't reading events, errors or replies
from the server, and that the server had run out of buffer space. When
this happened, the server waited a while (probably 30 seconds) and then
killed the link.
>I think that the problem is application independent because it works
>fine using the VAX Workstation Software.
I don't understand what this means.
James
|
| 2626.2 | debug with care | TOOLEY::B_WACKER | | Wed Apr 18 1990 14:16 | 4 |
| Remember that when you're sitting at a breakpoint you can't process
events, so choose breakpoints carefully and don't generate unnecessary
events while you're there. There's no guaranteed way to debug X
processes.
|
| 2626.3 | More information | MLNCSC::BELLENCHIA | R. Bellenchia - Product Support Italy | Thu Apr 19 1990 05:20 | 27 |
| RE:.1
>>I think that the problem is application independent because it works
>>fine using the VAX Workstation Software.
>I don't understand what this means.
This means that the debugger work fine using the VWS.
Before the status=2dba104, there is the following message "Using extra todo
packet pool". What does it mean ?
RE: .2
>Remember that when you're sitting at a breakpoint you can't process
>events, so choose breakpoints carefully and don't generate unnecessary
>events while you're there. There's no guaranteed way to debug X
>processes.
The server breaks the link immediately after the breakpoint established by the
customer.
So doing it prevents any actions from the customer. The system doesn't react
when the customer hits any character or shrinks the window to an icon or tries
to do anything.
Thanks in advance for any reply.
Roberto
|
| 2626.4 | | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Thu Apr 19 1990 13:30 | 15 |
| I don't know much about Phigs, but I wonder if the server might be generating
a large quantity of events either via X or via Phigs. For example, with X,
if the program mapped a whole slug of windows and then immediately hit the
break point, the server would then send a whole slug of expose events which
would not be serviced, and which could cause the server to react as above.
One thing that might help slightly, depending on what is generating the events:
If you call XSynchronize(dpy,1) at the start ONLY WHEN YOU ARE DEBUGGING!, Xlib
will send each request to the server as the request is made rather than buffering
them up. This might spread out any events which are being generated by the
request. Doing this also makes errors appear synchronously with the call that
created them. The disadvantage is that it is a LOT slower, and of course it
may mask some program errors due to assumed synchronicity.
Burns
|
| 2626.5 | Using extra todo packet pool is not an error | STAR::VATNE | Peter Vatne, VMS Development | Thu Apr 19 1990 14:29 | 5 |
| > Before the status=2dba104, there is the following message "Using extra todo
> packet pool". What does it mean ?
Ignore that message. It is essentially an internal debugging message.
It is not a problem unless you get several hundred of them...
|
| 2626.6 | | KONING::KONING | NI1D @FN42eq | Fri Apr 20 1990 14:06 | 4 |
| It sure would be nice if X treated temporary resource shortages in a more
sensible fashion.
paul
|