diff options
| author | Eli Zaretskii | 2001-12-06 12:35:13 +0000 |
|---|---|---|
| committer | Eli Zaretskii | 2001-12-06 12:35:13 +0000 |
| commit | 1d3adc2687e89ea2192f43e1b12e2d26bf734c8d (patch) | |
| tree | d9545128edd6546cd69739fd4deb5f1c7e949224 | |
| parent | c6ea27758c3c7e98dd2b60c7697ad970e9a002a3 (diff) | |
| download | emacs-1d3adc2687e89ea2192f43e1b12e2d26bf734c8d.tar.gz emacs-1d3adc2687e89ea2192f43e1b12e2d26bf734c8d.zip | |
Advice how to debug X protocol error which disappear in the
synchronous mode.
| -rw-r--r-- | etc/DEBUG | 43 |
1 files changed, 43 insertions, 0 deletions
| @@ -258,6 +258,49 @@ Setting a breakpoint in the function `x_error_quitter' and looking at | |||
| 258 | the backtrace when Emacs stops inside that function will show what | 258 | the backtrace when Emacs stops inside that function will show what |
| 259 | code causes the X protocol errors. | 259 | code causes the X protocol errors. |
| 260 | 260 | ||
| 261 | Some bugs related to the X protocol disappear when Emacs runs in a | ||
| 262 | synchronous mode. To track down those bugs, we suggest the following | ||
| 263 | procedure: | ||
| 264 | |||
| 265 | - Run Emacs under a debugger and put a breakpoint inside the | ||
| 266 | primitive function which, when called from Lisp, triggers the X | ||
| 267 | protocol errors. For example, if the errors happen when you | ||
| 268 | delete a frame, put a breakpoint inside `Fdelete_frame'. | ||
| 269 | |||
| 270 | - When the breakpoint breaks, step through the code, looking for | ||
| 271 | calls to X functions (the ones whose names begin with "X" or | ||
| 272 | "Xt" or "Xm"). | ||
| 273 | |||
| 274 | - Insert calls to `XSync' before and after each call to the X | ||
| 275 | functions, like this: | ||
| 276 | |||
| 277 | XSync (f->output_data.x->display_info->display, 0); | ||
| 278 | |||
| 279 | where `f' is the pointer to the `struct frame' of the selected | ||
| 280 | frame, normally available via XFRAME (selected_frame). (Most | ||
| 281 | functions which call X already have some variable that holds the | ||
| 282 | pointer to the frame, perhaps called `f' or `sf', so you shouldn't | ||
| 283 | need to compute it.) | ||
| 284 | |||
| 285 | If your debugger can call functions in the program being debugged, | ||
| 286 | you should be able to issue the calls to `XSync' without recompiling | ||
| 287 | Emacs. For example, with GDB, just type: | ||
| 288 | |||
| 289 | call XSync (f->output_data.x->display_info->display, 0) | ||
| 290 | |||
| 291 | before and immediately after the suspect X calls. If your | ||
| 292 | debugger does not support this, you will need to add these pairs | ||
| 293 | of calls in the source and rebuild Emacs. | ||
| 294 | |||
| 295 | Either way, systematically step through the code and issue these | ||
| 296 | calls until you find the first X function called by Emacs after | ||
| 297 | which a call to `XSync' winds up in the function | ||
| 298 | `x_error_quitter'. The first X function call for which this | ||
| 299 | happens is the one that generated the X protocol error. | ||
| 300 | |||
| 301 | - You should now look around this offending X call and try to figure | ||
| 302 | out what is wrong with it. | ||
| 303 | |||
| 261 | ** If the symptom of the bug is that Emacs fails to respond | 304 | ** If the symptom of the bug is that Emacs fails to respond |
| 262 | 305 | ||
| 263 | Don't assume Emacs is `hung'--it may instead be in an infinite loop. | 306 | Don't assume Emacs is `hung'--it may instead be in an infinite loop. |