PRODUCT: All X servers All X (MIT based) applications
OP/SYS: All Operating Systems
COMPONENT: X Servers/X applications
SOURCE: Philippe Vouters Fontainebleau/France
HIGH QUALITY MOBILES+TABLETS: http://android-land.fr
SYMPTOM(S) or PROBLEM(S): A complex X application succeeds to crash the X server. The crash symptom of the X server is an ACCVIO (VMS meaning) or, equivalent, a SIGSEGV (Unix/Linux meaning) or an X server debugger window (Windows meaning)
TROUBLESHOOTING GUIDELINES: Step 1: Using the UNCHANGED X application binary code, make thorough tests to exactly determine the hand manipulations which lead to the remote X server crash. Step 2: If not already available, download the latest version of Wireshark (tool available of Unix/Linux) or Ethereal (Windows) in their GRAPHICAL version. Ethereal and Wireshark are network tracers. Both tools are strictly functionaly equivalent, with perhaps one major difference imposed by the operating system they run on. This difference resides in the possibility to capture any network packet from any computer (promiscuous mode). Capturing in promiscuous mode is possible under Linux. As far as the author remembers, this ought to not be possible under Windows (Windows network limitation). The ideal thing if possible is to run Ethereal or Wireshark locally on the X application side and to not use promiscuous mode. Step 3: With Wireshark or Ethereal, capture the relevant traffic on IP port 6000 (the standard X server port). If either of these two network tracers runs locally, uncheck promiscuous mode and enter in the capture filter: "port 6000". If either of these two tools runs on a separate computer, make it work in promiscuous mode and filter using the following syntax for the filter: "(src or dst <X application side IP address>) and port 6000" For example, a tested syntax that works with Wireshark: (src or dst 192.168.1.2) and port 6000 Step 4: While either Ethereal or Wireshark runs, rerun your unchanged X application binary code and use the exact hand manipulations determined at Step 1. The root cause of the problem you are facing are in the last network frames which are logged by the two proposed network tracers. If you are an experienced Xlib application programmer, these two proposed network tracers are so powerful that using the last frames informations, you know how you can manage to build a very simple code which exemplifies the problem. Using the small Xlib code and its corresponding Wireshark network trace you save, anyone in charge of an X implementation may tell where the actual bug is sticking to the X protocol standard.
SO THAT YOU SEE WHAT YOU CAN EXPECT FROM WIRESHARK OR ETHEREAL: Take time to consider this Wireshark screen capture of a real X application executed with local display via an explicit $ export DISPLAY=127.0.0.1:0.0 You may find the full code of this real X application at: ../tima/X-MOTIF-1_2-and-2_1-programming-sample.html Here is the corresponding Wireshark screen capture the author's get, running the above code:
