bug#27816: 26.0.50; X protocol error: BadPixmap (invalid Pixmap parameter) on protocol request 55

[npostavs]

martin rudalics <rudalics@gmx.at> writes:

>> I don't get the Xaw3dComputeTopShadowRGB in my backtrace like Martin does:
[...]
>
> Maybe you should try calling ‘x-synchronize’ first.  Without that I can
> get all sorts of things like, for example,
>
> #0  x_error_quitter (display=0xe6dd60, event=0x7fffebd72bc0) at 
> ../../src/xterm.c:9855
> #1  0x000000000054763f in x_error_handler (display=0xe6dd60, 
> event=0x7fffebd72bc0) at ../../src/xterm.c:9828
> #2  0x00007ffa6360729a in _XError () from 
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> #3  0x00007ffa636045c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #4  0x00007ffa63604605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #5  0x00007ffa63604e95 in _XEventsQueued () from 
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> #6  0x00007ffa635f65ad in XPending () from 
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> #7  0x0000000000545aa4 in XTread_socket (terminal=0x1e23a38, 
> hold_quit=0x7fffebd72e20) at ../../src/xterm.c:9055
> #8  0x0000000000585ce8 in gobble_input () at ../../src/keyboard.c:6913
> #9  0x00000000005861ff in handle_async_input () at ../../src/keyboard.c:7150
> #10 0x000000000058621b in process_pending_signals () at 
> ../../src/keyboard.c:7164
> #11 0x000000000058625a in unblock_input_to (level=0) at 
> ../../src/keyboard.c:7179
> #12 0x000000000058627d in unblock_input () at ../../src/keyboard.c:7198
> #13 0x000000000053fdc6 in x_scroll_bar_create (w=0x156c7d0, top=37, left=1, 
> width=16, height=612, horizontal=false) at ../../src/xterm.c:6575
> #14 0x00000000005405f4 in XTset_vertical_scroll_bar (w=0x156c7d0, 
> portion=145, whole=145, position=0) at ../../src/xterm.c:6746
[...]


> But with ‘x-synchronize’ I reliably get the Xaw3dComputeTopShadowRGB
> bug.

Evaluating (x-synchronize t) in the first X frame doesn't seem to have
any effect for me.  My interpretation of the backtraces is that the
presence of XSync() indicates synchronous mode, and since yours lacks
that you are not actually in synchronous mode (I am somewhat out of my
depth here though, so perhaps this is nonsense).

>
> BTW could you try this with a motif build?  Here this gets me the backtrace
>
> #0  x_error_quitter (display=0x101b690, event=0x7fffaa9f2a60) at 
> ../../src/xterm.c:9855
> #1  0x0000000000547477 in x_error_handler (display=0x101b690, 
> event=0x7fffaa9f2a60) at ../../src/xterm.c:9828
> #2  0x00007f502555429a in _XError () from 
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> #3  0x00007f50255515c1 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #4  0x00007f5025551605 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
> #5  0x00007f50255521f8 in _XReply () from 
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> #6  0x00007f5025536e79 in XGetGeometry () from 
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> #7  0x00007f502638cd41 in size_cascade 
> (cascadebtn=cascadebtn@entry=0x1058230) at CascadeB.c:1851
> #8  0x00007f502638d713 in Initialize (w_req=0x7fffaa9f2ee0, w_new=0x1058230, 
> args=<optimized out>, num_args=<optimized out>) at CascadeB.c:2448
> #9  0x00007f5025e99490 in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
> #10 0x00007f5025e99e5f in ?? () from /usr/lib/x86_64-linux-gnu/libXt.so.6
> #11 0x00007f5025e9a2ab in _XtCreateWidget () from 
> /usr/lib/x86_64-linux-gnu/libXt.so.6
> #12 0x00007f5025e9a5ce in XtCreateWidget () from 
> /usr/lib/x86_64-linux-gnu/libXt.so.6
[...]

Attached are backtraces using lucid and motif.  The -x-commandline-synch
ones are where I used --eval '(setq x-command-line-resources
"emacs.synchronous: true")', the -x-synchronize-call are where I
evaluated (x-synchronize t) after creating the first X frame (and they
end up the same as the one where I did nothing, as I mentioned above).

bug-27816-badpixmap.tar.gz
Description: tarball with backtraces

> and the usual BadPixmap error.  So the bug behind all this is probably
> neither scroll bar nor menu related after all.  I conjecture that
> deleting the last GUI frame from a TTY started server messes up
> something we do not initialize properly when invoking another GUI client
> from it.  This conjecture is supported by the fact that when I leave a
> client frame open and fire up a new terminal, I can invoke the client
> from the new terminal as often as I want without any problems ...

> And I confirmed my conjecture here by using the attached patch.  Please
> try it.  I now start thinking that the GTK bug is not a GTK bug after
> all ...

With this patch I can't produce the badpixmap error here.