Thanks for the report.

I'm not in front of a Linux machine at the moment to confirm. Regardless, this issue does not seem to me to be high priority.

Most drivers hang when we're switched to another VT. It's an issue on Chrome OS too.
There's a hack on Chrome OS to ignore the watchdog when we're not on the expected X vt. I don't know if it can be generalized to linux desktop.

I have the same dmesg "watchdog segfault in chrome" message while watching youtube videos or (i think) some other WebGL content. It hangs computer and only reboot from tty can help.
Using Chrome 34.0.1847.116 on Ubuntu 13.10. What additional information should i provide?

@oxay91: does this happen while you're just viewing the X server or does it happen if you switch to another virtual TTY?

Could you attach the contents of about:gpu from your system to the bug report? An ASCII copy/paste is fine.

@kbr: It's happen while i'm viewing the X server.

Here's chrome://gpu :

Graphics Feature Status
Canvas: Hardware accelerated
3D CSS: Hardware accelerated
Compositing: Hardware accelerated
CSS Animation: Accelerated
Flash 3D: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Video: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
Problems Detected
Force compositing mode is off, either disabled at the command line or not supported by the current system.
Driver Bug Workarounds
clear_alpha_in_readpixels
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
disable_ext_occlusion_query
set_texture_filter_before_generating_mipmap
Version Information
Data exported	25.4.2014 9:48:36
Chrome version	Chrome/34.0.1847.132
Operating system	Linux 3.11.0-19-generic
Software rendering list version	0
Driver bug list version	4.1
ANGLE commit id	invalid-hash
2D graphics backend	Skia
Command Line Args	--flag-switches-begin --ignore-gpu-blacklist --flag-switches-end
Driver Information
Initialization time	27
Sandboxed	true
GPU0	VENDOR = 0x8086, DEVICE= 0x2e32
Optimus	false
AMD switchable	false
Driver vendor	Mesa
Driver version	9.2.1
Driver date	
Pixel shader version	1.20
Vertex shader version	1.20
Machine model	
GL version	2.1
GL_VENDOR	Intel Open Source Technology Center
GL_RENDERER	Mesa DRI Intel(R) G41
GL_VERSION	2.1 Mesa 9.2.1
GL_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_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_3DFX_texture_compression_FXT1 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_filter_anisotropic 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_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc 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_ATI_envmap_bumpmap GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp 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_depth_clamp 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_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_packed_depth_stencil GL_APPLE_object_purgeable GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_texture_array GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_MESA_texture_array GL_ARB_copy_buffer GL_ARB_depth_buffer_float 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_ARB_ES2_compatibility GL_ARB_debug_output 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_seamless_cube_map GL_ARB_shader_texture_lod GL_ARB_texture_rgb10_a2ui GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_ARB_get_program_binary GL_ARB_robustness GL_ARB_shader_bit_encoding GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_internalformat_query GL_ARB_texture_storage GL_ARB_invalidate_subdata
Window system binding vendor	SGI
Window system binding version	1.4
Window system binding extensions	GLX_ARB_create_context GLX_ARB_create_context_profile GLX_ARB_multisample GLX_EXT_create_context_es2_profile 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
Reset notification strategy	0x8261
Log Messages
[17383:17383:0425/064629:WARNING:x11_util.cc(1545)] : X error received: serial 4787, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)

@oxay91: the issue you're seeing is something different than this bug describes. I suggest filing another bug and providing the about:gpu information above, the window manager you're using, the model of your computer, and clear and simple reproduction steps. Feel free to post the bug ID here once filed.

Is the GPU in your machine officially an Intel HD Graphics 4000 or 4500, or something else? It's not clear to me what the G41 chipset describes.

G41 is GEN4 (also known as the first i965 GPU), it's from 2008 or so. It is not HD graphics 4000/4500 which is GEN7.

As for the original bug, I landed a Chrome OS specific patch to handle this a while ago. If folks feel that we should do the same for Linux, it is easy to do.

I can confirm this bug, running an i965GM but I don't think that's what
matters (?), it's the VT switch.  Followed reproduction steps and this
reliably segfaults GPU process every time.

Mar 12 18:06:17 dnsmasq[9337]: forwarded get.webgl.org to 8.8.8.8
Mar 12 18:06:17 dnsmasq[9337]: reply get.webgl.org is 50.23.225.116
Mar 12 18:07:12 X: (II) AIGLX: Suspending AIGLX clients for VT switch 
Mar 12 18:07:23 vmunix: [213447.703443] Watchdog[5434]:
                segfault at 0 ip 00007fa1d1444326 sp 00007fa1bf9f8620
                error 6 in chromium[7fa1cd5e9000+5e4b000]
Mar 12 18:07:23 wm: [5427:5434:0313/010723:ERROR:gpu_watchdog_thread.cc(253)]
                The GPU process hung. Terminating after 10000 ms.
Mar 12 18:07:23 wm: [5392:5392:0312/180723:ERROR:gpu_process_transport_factory.cc(514)]
                Lost UI shared context.
Mar 12 18:07:33 vmunix: [213457.872648] Watchdog[20187]:
                segfault at 0 ip 00007fe949894326 sp 00007fe937e48620
                error 6 in chromium[7fe945a39000+5e4b000]

Running stock Debian 8 chromium/kernel/mesa/xorg on this machine.
Beforehand, about://gpu shows good hardware accelerations.  Afterwards
(reloading about://gpu tab), hwaccel is disabled.  Chromium continues to
run and X is still working fine, but all graphics are then using the
software implementations after return to X from any other VT.

This bug affects anyone running a separate X server on anything else on
another VT (directfb or wayland or fbterm or...) I'd like to be able to
use these VTs for other things without crashing Chrome.

Perhaps you can inotify_add_watch(2) on /sys/class/tty/tty0/active and
handle changes by disabling the watchdog until it's been restored to the
startup value.  This would break if starting Chromium using eg 
"DISPLAY=:0 chromium" from a different console or X server though...

there must be some X event you could listen for... perhaps since X
suspends AIGLX clients prior to switch, you could register yourself as
one, and suspend the watchdog when that happens.

 Issue 392777  has been merged into this issue.

392777 shows that this can happen with light-locker.

 Issue 389816  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9db5a0e3f53edfa3cc653d9d6f8476c17bc7d2b9

commit 9db5a0e3f53edfa3cc653d9d6f8476c17bc7d2b9
Author: thomasanderson <thomasanderson@google.com>
Date: Fri May 20 01:57:02 2016

Don't exit the GPU process if on a non-host TTY

Requests to the X11 server may be stalled if we switch away from the
TTY that is hosting the X server.  In this case, don't restart the GPU
process as it will become responsive again when we switch to its TTY.

BUG= 355720 

Review-Url: https://codereview.chromium.org/1991353002
Cr-Commit-Position: refs/heads/master@{#394957}

[modify] https://crrev.com/9db5a0e3f53edfa3cc653d9d6f8476c17bc7d2b9/content/gpu/gpu_watchdog_thread.cc
[modify] https://crrev.com/9db5a0e3f53edfa3cc653d9d6f8476c17bc7d2b9/content/gpu/gpu_watchdog_thread.h

Hello everyone,
I have been having this bug since about one year ago, running Xubuntu 14.04, 15.04, and now a fresh install of 16.04.
It happens both with Chromium and with Google Chrome.

I don't know if the following will help, yet I wanted to throw it out there:
Once the browser is "stuck" without doing a refresh of its contents, you can "refresh" it by switching workspaces (I am running Xubuntu 16.04, thus Xfce).
Say you go to the stuck browser window, hit Ctrl + T, yet a new window does not show up... switch workspaces, and when you come back, the new tab is there, opened.

Another side-note that might help: In my workstation, this does not happen, yet it does come up in the laptop.
Only difference is in the laptop I have light-locker installed and running.

Thank you for your help!

Hello everyone,
I wanted to add another information point which might help:
I started my laptop, and did not log in... it was just left idling for 25-30 minutes.  
I then logged into the laptop, and started Google Chrome... and the same behavior happened again: Chrome was "frozen".

Yet if you change workspaces, Chrome does "refresh" the content.

Hope this helps.

Can anyone still repro with 52.0.2743.0 or later?

I have NOT seen Chromium to lock up when switching to other VTs in Version 51.0.2704.79 Ubuntu "Trusty" 14.04 (64-bit), or the same version number in "Xenial" 16.04. 

My workaround to avoid the freezes was to turn off Use Hardware Acceleration under Advanced settings, so I have turned that back on and will continue watching.

Chromium used to lock up when using the Xubuntu lock screen as described in  Bug #392777  (merged with this bug) but after upgrading to Xenial the desktop behavior differs somehow (maybe just on my hardware) so I'm not certain I'm testing the same software interaction anymore.

related  issue 427909 

 Issue 427909  has been merged into this issue.

 Issue 400043  has been merged into this issue.

I think thomasanderson's https://chromium.googlesource.com/chromium/src.git/+/9db5a0e3f53edfa3cc653d9d6f8476c17bc7d2b9 is about as well as we'll do on this. Closing this as fixed. Please file a new bug with clear reproduction steps if more work is needed.