Conference bulova::decw_jan-89_to_nov-90

I'll try to figure out what is at those PC values.  BTW, is the application
doing an XSynch or something to force the buffer to be flushed before each
�-second wait?  If not, try it.  There is still a bug if the server loops, but
it might do something.

Burns

    RE: 1.
    Thank you for trying to help me out.
    In the standard application we don't synch, but in the minimized
    version we tried it without any success. I will try to put it in the
    standard appliction and post the result. 
    By the way, the wait is not �-second, it's 4 seconds.
    
    Gert.

    My excuses to anybody who have tried to reach the files mentioned in
    the base note. Someone of our system managers made a too good job.
    The mentioned files is available as follows:
    
        Directory STKTSC::SWS4:[GOLSSON]   
        
        MAIN.XL;1               183/183    
        MAIN_MIN.XL;1           211/213    
	GRAPH.PAS;197           859/861    
        INPUTDRIVERS.PAS;66                
                                135/135    
    
    
    Gert.

    RE: 1
    We have tried to put in a lot of X$Synch and/or X$Flush but the problem
    remains the same as described in the basenote.
    
    We are working on tracing all XLib calls and generate a smaller
    program out of that. We will post it here ifit fails the same way as
    the "big" application is doing.
    
    Gert.

    We have managed to reduce the code that generates the problem.
    
    If anyone want to try it or wants to give som suggestions for 
    workarounds, are welcome and can get it from the following:

	Directory STKTSC::SWS4:[GOLSSON]
	DECW_KILLER_MINI.PAS;2   25
	DECW_KILLER_MINI.XL;1     7
    
    The code isn't beatiful, as most of it is generated by tracing Xlib calls,
    so please don't shout at me for that.
    
    Gert.

It would have saved me several hours of work if this bug
had been QAR'ed.  I came across another program that
appears to cause the server to loop in the same way.
I checked the QAR files for reported server bugs, didn't see any, 
so I then spent several hours generating crash dumps and investigating
the problem.

Once a problem is understood to be a bug in a DECwindows component,
it needs to be QAR'ed.

grrrr.

    RE: .6
    Excuse me, but I hasn't been sure that this is a server bug (and
    still I'm not 100% sure about it, probably due to my limited knowledge
    of the VMS X-Server).
    
    We have also spent time trying to reduce the code that exhibits the
    "loop problem" to a more manageble amount to ease the SPR/QAR
    process.
    
    I have use this note as a way to help me with this, and I hope that
    that isn't a missuse of this conference. If so, I apologize.
    
    But of course you are right about the QAR system, I should have
    checked it for similar bugs very carefully. The main obstacle on
    the way is that I dont know where it is! Could anyone tell me?
    
    Gert.

    Cont from .7:
    
    Excuse me again, I should of course know that the QAR system lives on
    TRIFID.
    
    It's not easy to use from this side of the Atlantic, but anyway, I'll
    try to check out QAR 2353 and see if it fits, else I think we have a
    well defined problem to put in.
    
    Gert.

    The problem is QAR:ed as #2357 in DECWINDOWS_IFT at TRIFID.
    
    I had some problem entering the QAR, partly due to not being used
    to the QAR system, partly due to the long response times across
    the Atlantic.
    
    Gert.

One trick to help with using TRIFID from far away is to
create the QAR text file on your local system.  Make the
file world readable, then set host to TRIFID.  Ask for
the editor to create the QAR, then just type at the editor prompt
* INCLUDE MYNODE::MYDISK:[MYDIR]MYFILE.TXT.
This step may take a few minutes, but you don't have to waste
your time while this is happening.

Thanks for entering the QAR.

    This may be impropriate, but I ask anyway.
    
    Can anyone from DECwindows group give us or me any feedback on the
    QAR I entered for this problem? (QAR #2357, DECWINDOWS-IFT)
    
    The QAR is open and has gotten it's component and abstract fields
    filled in.
    
    Gert.

I'm looking at it at this very moment.  I have gotten the "minimized" version,
but I can't reproduce the problem.  It seems to run fine.  I'm getting the
liddy log now to see if I can tell anything.

Burns

I'm not getting much of anywhere with this.  Everything seems to work fine
for me.

In the liddy log, did you ^Y the client after the hang started?  That is,
is it reasonable to assume that the last thing in the liddy log is the
last instruction sent to the server?

Burns

    Yes, we interrupted the client with ^Y, stopped it and then stopped
    the XLIDDY process.
    
    To bad that you can't get it to fail. I tried today again with same
    result. As you probably have read before we have the problem on both
    a VS2000, 4 plane color, 6Mb and a VSII GPX 8 planes, 9 Mb. The
    problems shows up with both EFT-2 and 5.1 SDC (Easynet kit) software.
    
    Are you trying it out in that environment or something newer?
    If you have newer software we are of course willing to try it too see
    if it helps!
    
    Gert.

    I'm running regular old SDC V5.1 on a 5(?)-meg VSII/GPX with 8-planes.
    
    I also tried it on a 24-plane Firefox, but that didn't work for beans.
    You should probably search for a PseudoColor visual at the beginning
    rather than assuming that the default visual is PseudoColor.
    
    But I honestly don't know what is going on.  Next thing I will do is
    to try to figure out what the addresses you mention earlier are.  Just
    to double check, could you enter here the addresses in your server log?
    It should say something like "Device Independent Loaded at <hex address>"
    and then "GPX Color Support Loaded at <hex address>".  That's not quite
    the right words, but you can find it pretty easily, and that is what I
    would like, please.
    
    Burns
    

    After a failing run both DECW$SERVER_0_ERROR.LOG and OUTPUT.LOG is
    empty.
    
    I have included a DECW$SERVER_0_ERROR.LOG from a normal run.
    
    Gert.
    
Hello, this is the X server
Dixmain address=22dfa
Now attach all known txport images
in SetFontPath
out SetFontPath
GPX color/monochrome support loaded
gpx$InitOutput address=1138d4
Connection Prefix: len == 42
Now I call scheduler/dispatcher
Connection aa578 is closed by Txport
Connection aa578 is closed by Txport
Connection ac490 is closed by Txport
Connection ac4c8 is closed by Txport
Connection ac4c8 is closed by Txport
Connection ac4c8 is closed by Txport
Connection ac4c8 is closed by Txport
Connection
    

    A little observation:
    
    I've tried the "mini_killer" several times today with failures.
    One thing though, if i compile, link and run it with debugger,
    it works most of the time. So to be sure of failure run it without
    any debugging.
    
    Gert.

    There is a workaround to solve this problem. (See QAR #2357)
    There will also be a fix to the server in the feature.
    
    Basically the problem is that the server doesn't mask out the
    appropriate bits in the X$Color.X$Colr_Flags structure when defining
    a color. Especially if the sign bit in this byte is set the server
    goes into a compute loop.
    
    The workaround is to clear this byte before setting any of the flags.
    
    Thanks to everybody who helped me to get this sorted out.
    
    Regards,
    Gert.

Sorry I did not post the fix here too, but thanks to Gert for relaying the
info from the QAR system.  I presume that this fixed your problem, Gert?

Thanks to everyone for the help...it was easy to find once I could reproduce
it, but reproducing it was a bear.  Andy came up with the program that did it.

Burns

    RE: .19
    
    Sure it fixed my problem, thanks for the help!
    
    Gert.