bug#16737: Timed out waiting for reply from selection owner

[Alex Bennée]

I couldn't get that patch to apply. However it looks like the list of
fd's is null:

Program received signal SIGINT, Interrupt.
0x00007fe50beaaeb9 in __pselect (nfds=<optimised out>,
readfds=<optimised out>, writefds=<optimised out>,
exceptfds=<optimised out>, timeout=<optimised out>, sigmask=<optimised
out>)
    at ../sysdeps/unix/sysv/linux/pselect.c:78
78      ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
(gdb) bt
#0  0x00007fe50beaaeb9 in __pselect (nfds=<optimised out>,
readfds=<optimised out>, writefds=<optimised out>,
exceptfds=<optimised out>, timeout=<optimised out>, sigmask=<optimised
out>)
    at ../sysdeps/unix/sysv/linux/pselect.c:78
#1  0x00000000006c3843 in xg_select (fds_lim=28, rfds=0x7fff90d8d8d0,
wfds=0x0, efds=0x0, timeout=0x7fff90d8d8b0, sigmask=0x0) at
xgselect.c:105
#2  0x000000000066bb23 in wait_reading_process_output (time_limit=5,
nsecs=0, read_kbd=0, do_display=false, wait_for_cell=14274358,
wait_proc=0x0, just_wait_proc=0) at process.c:4603
#3  0x00000000005537bb in x_get_foreign_selection
(selection_symbol=14059234, target_type=14325826, time_stamp=14016754,
frame=62671861) at xselect.c:1237
#4  0x00000000005558f2 in Fx_get_selection_internal
(selection_symbol=14059234, target_type=14325826, time_stamp=14016754,
terminal=14016754) at xselect.c:2017
#5  0x0000000000613d7d in Ffuncall (nargs=3, args=0x7fff90d8dcc8) at eval.c:2826
#6  0x000000000065e8d7 in exec_byte_code (bytestr=11267393,
vector=11267429, maxdepth=28, args_template=14016754, nargs=0,
args=0x0) at bytecode.c:916
#7  0x00000000006148d9 in funcall_lambda (fun=11267301, nargs=1,
arg_vector=0xabed65 <pure+1341573>) at eval.c:3049
#8  0x0000000000613edd in Ffuncall (nargs=2, args=0x7fff90d8e1e0) at eval.c:2864
#9  0x000000000065e8d7 in exec_byte_code (bytestr=11250537,
vector=11250573, maxdepth=16, args_template=1028, nargs=1,
args=0x7fff90d8e730) at bytecode.c:916
#10 0x00000000006144ee in funcall_lambda (fun=11250485, nargs=1,
arg_vector=0x7fff90d8e728) at eval.c:2983
#11 0x0000000000613edd in Ffuncall (nargs=2, args=0x7fff90d8e720) at eval.c:2864
#12 0x000000000060c8aa in Fcall_interactively (function=21920738,
record_flag=14016754, keys=14051741) at callint.c:836
#13 0x0000000000613d4a in Ffuncall (nargs=4, args=0x7fff90d8e9c8) at eval.c:2822
#14 0x000000000065e8d7 in exec_byte_code (bytestr=10843817,
vector=10843853, maxdepth=52, args_template=4100, nargs=1,
args=0x7fff90d8ef00) at bytecode.c:916
#15 0x00000000006144ee in funcall_lambda (fun=10843773, nargs=1,
arg_vector=0x7fff90d8eef8) at eval.c:2983
#16 0x0000000000613edd in Ffuncall (nargs=2, args=0x7fff90d8eef0) at eval.c:2864
#17 0x0000000000613644 in call1 (fn=14060610, arg1=21920738) at eval.c:2614
#18 0x000000000056d335 in command_loop_1 () at keyboard.c:1559
#19 0x00000000006103b2 in internal_condition_case (bfun=0x56cb99
<command_loop_1>, handlers=14068322, hfun=0x56c30c <cmd_error>) at
eval.c:1354
#20 0x000000000056c819 in command_loop_2 (ignore=14016754) at keyboard.c:1177
#21 0x000000000060f836 in internal_catch (tag=14064258, func=0x56c7f3
<command_loop_2>, arg=14016754) at eval.c:1118
#22 0x000000000056c7c7 in command_loop () at keyboard.c:1156
#23 0x000000000056be17 in recursive_edit_1 () at keyboard.c:777
#24 0x000000000056bffc in Frecursive_edit () at keyboard.c:848
#25 0x0000000000569f3a in main (argc=2, argv=0x7fff90d8f398) at emacs.c:1646
(gdb) frame 1
#1  0x00000000006c3843 in xg_select (fds_lim=28, rfds=0x7fff90d8d8d0,
wfds=0x0, efds=0x0, timeout=0x7fff90d8d8b0, sigmask=0x0) at
xgselect.c:105
105       nfds = pselect (fds_lim, &all_rfds, have_wfds ? &all_wfds : NULL,
(gdb) p fds_lim
$1 = 28
(gdb) p all_rfds
$2 = {fds_bits = {2048, 0 <repeats 15 times>}}
(gdb) c
Continuing.

On 25 June 2014 19:28, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hi.
>
> 25 jun 2014 kl. 18:04 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>
>> forcemerge 17026 16737
>> thanks
>>
>> Do you guys still experience those hangs?
>> Any hope of getting a vaguely reproducible recipe?
>>
>> Jan, is there some debugging code we could add somewhere around the
>> *select code which could help us track down the source of the problem?
>
> If it times out, it is because we don't get the PropertyNotify we expect.
> There is some TRACE one can turn on in xselect.c by defining TRACE_SELECTION.
>
> But we should add something like this (totally untested, not even compiled):
>
> === modified file 'src/xselect.c'
> --- src/xselect.c       2014-01-01 07:43:34 +0000
> +++ src/xselect.c       2014-06-25 18:27:16 +0000
> @@ -1144,8 +1144,19 @@
>  {
>    struct prop_location *rest;
>
> +  fprintf (stderr, "Got property notify for %s, %s, %lu %p\n",
> +           (event->state == PropertyDelete ? "deletion" : "change"),
> +           XGetAtomName (event->display, event->atom),
> +           (unsigned long)event->window,
> +           event-display);
> +
>    for (rest = property_change_wait_list; rest; rest = rest->next)
>      {
> +      fprintf (stderr, "Check property notify against %s, %s, %lu %p\n",
> +               (rest->desired_state == PropertyDelete ? "deletion" : 
> "change"),
> +               XGetAtomName (rest->display, rest->atom),
> +               (unsigned long)rest->window,
> +               rest->display);
>        if (!rest->arrived
>           && rest->property == event->atom
>           && rest->window == event->window
> @@ -1166,6 +1177,7 @@
>           return;
>         }
>      }
> +  fprintf (stderr, "No property match\n");
>  }
>
>         Jan D.
>



-- 
Alex Bennée
KVM/QEMU Hacker for Linaro