X server error

[Nick_135]

I do not know where exactly to post this, but maybe someone can point me in the right direction...

Running HPUX 11i. Our software that we are using randomly crashes without warning with only the following output "Fatal IO error: client killed". This usually happens with the user is making a normal action like clicking on an "ok" button or clicking in a text box. It cannot be duplicated and we are stumped to what is causing it. Our software is developed on Mandrake and we are using Trolltech's QT toolkit. We then port it to HPUX for some of our users. In our limited testing, we have not seen this on linux. Trolltech has stated that for some unknown reason, our application is being disconnected from the X server. Is there any debug that we can turn on or third party software that may be able to lend us a hand?

[Sanjiv Sharma_1]

Hi Nick,

I would first check that the HP-UX 11i, the PC/Workstation on which Xserver is running has the latest patches installed.

[Steven E. Protter]

I would recommend a process trace to get a specfic reason for the application dying.

If the process lives long enough you might try tusc.

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.5/

It can collect information and help you verify if your port works.

If it works on some HP-UX clients and not others, its probably kernel parameters doing you in. maxusers to increase nproc,nfiles

SEP

[Printaporn_1]

Hi,

any messages logged to /var/dt/Xerror ?

HTH.

[Rick Beldin]

Fatal IO error is the message printed out by Xlib's fatal IO error handler. The errno that is displayed can serve to isolate, but usually isn't that helpful. A problem with fatal IO errors in X is that by specification, the program *must* exit when it encounters one.
Fatal IO errors could come from sockets that are closed (common in network environments) or a corrupt fd (programming problem) or some other failure that is causing X to fail on a read or a write to the socket that the Xserver has open.

You can setup your own error handler with XSetIOErrorHandler() and then you could do something like call the HP-UX function U_STACK_TRACE(). This would give you a stack trace of where you were at the time of the failure. Once you exit this function, the library will call exit() and your program will exit.

If you can reproduce the problem reliably, you might compile your code with -g, and use gdb. Set a breakpoint on _exit (b _exit) and then continue. When the program hits _exit it will either be because the program encountered this error or someone is exiting the program. At that point, you can get a stack trace and debug it.

[Nick_135]

Thanks for all the information and tips. We will further investigate the problem and I will post a new message if we find anything out.