| Title: | DECWINDOWS |
| Notice: | DECwindows Motif V1.2-4 SSB kits: note 5519 |
| Moderator: | GRIM::MESSENGER |
| Created: | Wed Nov 28 1990 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5861 |
| Total number of notes: | 24081 |
Hi, I have no experience in X-Application development, so sorry if some questions are too simple or too vague ... I should help to one of our customer with the following strange problem: Customer has a ig formerly GKS-Based Program, which now should get X Interface. Anything seems to be OK, but after some mouse clics (2 to almost 500) his pointer initialisation subroutine (1st one in long pointer device initialisation chain) bombs out with access violation. Analyze (both DEBUGger and ANA/SYS) shows that some junk (always quadword 0X2C) was written into stack at the place where the procedure parameters are copied from linkage registers. This happens only with this subroutine and at different places. By example, if the subroutine is instrumentalized with debug fprint's (if(a==0) fprintf ... ) then the fprintf after the 3d original statement is triggeren. Debug (stepwise) shows corruption in the first statement. It looks like, that some other routine has initialized an asynchronous action (something like AST) giving it address of one of local variables as parameter. Then this routine is gone and pointer initialisation routine got its place on stack. When action routine is triggered it writes some data to stack where instead of local variables of initiator routine parameters of pointer device initialisation routine are placed ... 1. Is such scenario possible ? 2. Does Xlib use AST's to implement it's events ? (customer said, that disabling user mode AST didn't help) 3. Which other debug techniques can I use to log all X-events happened ? TIA =Seva
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5813.1 | Versions ... | COL01::VSEMUSCHIN | Duck and Recover ! | Tue Mar 25 1997 06:52 | 9 |
Sorry, This error happened on different computers under OVMS 6.2-1H2 and 7.1, Motif 1.2-3. It looks like (customer said) that error will not happen if the station is a part of VMScluster. =Seva | |||||
| 5813.2 | Sounds Like AST Stack Corrupter... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed Mar 26 1997 10:31 | 15 |
I'll bet the customer has a mis-declared variable and/or IOSB around somewhere -- either a string buffer that's too short, a variable such as an IOSB that accessed via an asynchronous operation that's not in storage that is nonvolatile over the potential life of the asynchronous call (stack-local IOSBs are notorious here), a completion operation that is not synchronized, a routine that is mis-behaving as a result of a spurious event flag event, etc. In this particular case, I'd look carefully for problems in any of the other (previously-executed) subroutines that would execute at the "same" stack depth as the failing routine... Without examining the entire module, it's diffult to point at any particular problem... | |||||
| 5813.3 | moved to VMSNOTES | COL01::VSEMUSCHIN | Duck and Recover ! | Wed Mar 26 1997 14:19 | 20 |
Yes, Steve, I too think (.0) that it is a volatile varibale that is
modified by asynchronous action. Btw. thank you for the Idea with
IOSB. It is exactly quadword and 0x2c is SS$_ABORT ...
But it is too hard to examine the source code. This program consists of
two parts, first, main program, is an old FORTRAN/GKS code, second,
shareable image, is new C++ X-Programming example. I suspect, that people
that wrote it would like to enter 5 more variables and 3 extra statement
nesting levels to avoid single goto - so is their understandig of
structure programming. To reach Xt library calls I should go through
6-7 levels of programs consisted mostly of only one statement. And
of course because such code is self-explanatory guys didn't wrote
any comment ... Besides it it is a protable code that should work
perfectly in any U*X system, so it is hopeless to look there
for IOSB's. It was a reason to ask it here.
Now I re-asked this question in VMS notes conference. Please post
your further answers there.
=Seva
| |||||
| 5813.4 | VMSNOTES 386.* ... | COL01::VSEMUSCHIN | Duck and Recover ! | Wed Mar 26 1997 14:24 | 1 |