--term xterm causes kmscon to get "stuck"

[bluetech]

I have an issue where I start kmscon, where the session is something like this:

$ ls / / /home for bar baz

And then the prompt doesn't appear again. VT switching still works, so it's not some infinite loop. I bisected this to commit a0c644f3b35 which changed the default TERM to xterm-256color (but it also happens with just xterm). It doesn't happen with TERM=vt220.

After switching to another VT and attaching gdb to kmscon, the bt is:

0 0xb773b424 in __kernel_vsyscall ()

1 0xb747ee78 in __epoll_wait_nocancel () from /usr/lib/libc.so.6

2 0xb7716a6e in ev_eloop_dispatch (loop=loop@entry=0x9e460c0, timeout=timeout@entry=-1) at src/eloop.c:808

3 0xb771705e in ev_eloop_run (loop=0x9e460c0, timeout=timeout@entry=-1) at src/eloop.c:895

4 0x0804b53d in main (argc=1, argv=0xbfe78e84) at src/main.c:624

So nothing helpful here. When attaching to the bash process, the bt is:

0 0xb77b6424 in __kernel_vsyscall ()

1 0xb763b6b3 in __read_nocancel () from /usr/lib/libc.so.6

2 0xb7788b84 in rl_getc () from /usr/lib/libreadline.so.6

3 0xb778941b in rl_read_key () from /usr/lib/libreadline.so.6

4 0xb777302c in readline_internal_char () from /usr/lib/libreadline.so.6

5 0xb7773585 in readline () from /usr/lib/libreadline.so.6

6 0x0805cdca in ?? ()

7 0x0805e90e in ?? ()

8 0x080614e3 in ?? ()

9 0x08064622 in yyparse ()

10 0x0805c6cd in parse_command ()

11 0x0805c78d in read_command ()

12 0x0805c9d7 in reader_loop ()

13 0x0805acfa in main ()

So it just waits for user input as well. So I don't know where to look (I can bisect further back with setting --term manually if you don't have a quick idea).

Since it clearly doesn't happen to other people, some details of this machine:

uname -a: Linux fst 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 08:15:06 UTC 2012 i686 GNU/Linux

packages: extra/mesa 8.0.4-3 [installed] extra/libdrm 2.4.39-1 [installed] extra/intel-dri 8.0.4-3 [installed]

glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301) OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_fog_distance, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_primitive_restart, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_compression_rgtc, GL_ARB_texture_float, GL_ARB_texture_rectangle, GL_ATI_texture_compression_3dc, GL_EXT_packed_float, GL_EXT_pixel_buffer_object, GL_EXT_texture_compression_rgtc, GL_EXT_texture_mirror_clamp, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_texture_shared_exponent, GL_ARB_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_packed_depth_stencil, GL_ARB_vertex_array_object, GL_ATI_separate_stencil, GL_ATI_texture_mirror_once, GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_gpu_program_parameters, GL_EXT_texture_compression_latc, GL_EXT_texture_sRGB_decode, GL_OES_EGL_image, GL_ARB_copy_buffer, GL_ARB_draw_instanced, GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, GL_ARB_map_buffer_range, GL_ARB_texture_rg, GL_ARB_texture_swizzle, GL_ARB_vertex_array_bgra, GL_EXT_separate_shader_objects, GL_EXT_texture_swizzle, GL_EXT_vertex_array_bgra, GL_NV_conditional_render, GL_AMD_draw_buffers_blend, GL_ARB_ES2_compatibility, GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_provoking_vertex, GL_ARB_sampler_objects, GL_ARB_shader_texture_lod, GL_ARB_vertex_type_2_10_10_10_rev, GL_EXT_provoking_vertex, GL_EXT_texture_snorm, GL_MESA_texture_signed_rgba, GL_ARB_robustness, GL_ARB_texture_storage

[dvdhrm]

That is really weird. If I had to guess, then I would say your bash uses some other configuration that depends on some unimplemented xterm functionality in kmscon. --term=xterm probably never worked on your machine?

Could you run with --debug and append the log here? (or http://gist.github.com) It would be also interesting whether data is still sent to and received from bash. You could add a debug statement to send_buf() in src/pty.c and pty_input() in src/pty.c.

I happened to invoke ctrl+ accidentally when switching VT to kmscon. There are some keyboard-shortcuts that can suspend data transmission in bash. What happens if you press ctrl+c in your case? But you say it works with vt220 so this confuses me the most. kmscon does pretty much the same whatever TERM is set to so this really looks like some incompatibilites with bash+xterm-mode. --debug log should probably help here.

I will think a bit more about this but both backtraces you posted look pretty normal. Thanks David

[bluetech]

So I tried going a bit further, and it seems it really never worked a1b2202 is the last commit I could get to compile without messing around, and it's the same as above.

As per your suggestion, I see that bash actually keeps working, stuff is just not printed to the screen. So if I do 'script -f' to a file I see the stuff that I write, the command output, etc. I guess that means pty is fine? Also other shells (dash, zsh) and other readline programs work, so I currently only get this bug with bash+xterm (with a clean bash config).

I added debug statements to kmscon_vte_handle_keyboard and write_console. I start kmscon, switch to the VT, get a bash prompt, write ": pressing enter" followed by enter, and than I write "I CANT SEE THIS" (which I can't see, he): https://gist.github.com/3736601

Besides that the only vte-related message is: [0000.051473] DEBUG: vte: unknown DEC Set-Mode 1034 (csi_mode() in src/vte.c:1370) which is xterm specific but I'm pretty sure is not the problem?

[dvdhrm]

The log looks pretty normal, indeed. The DEC Set-Mode is actually about the Meta-key so we can ignore it. And pty seems ok, too.

As a temporary workaround, you can set "term=vt220" in /etc/kmscon.conf btw. And can you also try TERM=xterm-color please? xterm-color is actually a smaller subset of xterm and xterm-256color and avoids many xterm features. Or you can also try urxvt or some similar values. Because I really think this is some missing xterm feature that kmscon does not implement.

I am currently working on moving all terminal emulation into an independent state-machine (called TSM) and then I will try to add a debug-log that prints all escape sequences that are sent or received. This should make debugging much easier.

Other than that, I am currently out of ideas... Sorry Thanks David

[dvdhrm]

Ah, maybe you can also test some other very trivial terminal-emulator (like EFL-terminology, weston-terminal or some other) and set TERM=xterm and see whether they work. (or maybe even test gnome-terminal/libvte, Konsole, urxvt or something like this).

Because reading xterm code is horrible and maybe I can get some clue where it fails.

[bluetech]

Okay, I looked again at the 'script -f' output and I think I see what's going on. The sequence at blame is: \e]0;MY TITLE\a This is an OSC sequence which sets the title in xterm, see the "Operating System Controls" section in ctlseqs.html. Notice that BEL and ST should terminate the parameter. I think the vte state machine gets stuck in the OSC_COLLECT state, or something of the sort. Even with --term=vt220, when I cat a file with this sequence the text stops appearing. Don't know why it only happens to me though, might be something else yet.

In any case I've been using vt220 as you suggested so it's OK. Thanks!

[dvdhrm]

Indeed, this sequence is not correctly terminated in the eyes of kmscon. It expects ST at the end of OSC strings. This also explains the behavior as kmscon is constantly collecting more data for OSC strings. A manual ST should be a workaround, too (echo -e "\x9c" or something like this). I don't know why xterm allows BEL for OSC termination. No official VT terminal seems to support this (I cannot find this in any documentation) and no-one of us discovered bash using it.

http://vt100.net/emu/dec_ansi_parser This is the state-machine that I implemented as parser and I haven't had any problems with it. Well, I should report it to Paul Williams, too.

Thanks a lot for bisecting and investigating in this. I will fix it tomorrow morning! David

[dvdhrm]

I just pushed 92a14e0964ef0d653785559e95b1a70393e73254 to the repository. I hope this fixes it.

Thanks again for your efforts! David