Crash compiling example006: builtin_textureGradOffset: Process /usr/bin/openscad was killed by signal 6

[hroncok]

Hi,
I've build packages for Fedora and we have first bug report from Automatic Bug Reporting Tool: https://bugzilla.redhat.com/show_bug.cgi?id=889785 (look at the attachments)

If I test it on my machine, I can render [F6] the example, but cannot compile [F5] it. Openscad doesn't crash, but it hangs up after CSG Products normalization.

The build is 1 commit behind master (b04734c) and the last commit seems Linux irelevant.

I can reproduce the hang at development version downloadable from openscad.org.

Thanks a lot for help.

[hroncok]

If I comment out first for (edgeprofiles) or the second for (round holes - dice value) it compiles. If they are together, it hangs.

[donbright]

From the (very impressive) report details, it looks like maybe, possibly OpenCSG is calling some kind of OpenGL OcclusionQuery stuff in the i965_dri.so (Intel 965) graphics driver on 64bit and it's not going well. . . .

the i965 brw_begin_query function is here in Mesa:
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_queryobj.c

hroncok: are you on 32 bit or 64 bit?

One thing you might try, is to go to OpenSCAD/edit/preferences/advanced/opencsg/goldfeather, turn it off and/or on, and see if that makes a difference.

I am on 32 bit ubuntu 12.04 and cannot reproduce the hang nor the crash.

I also tried it on RHEL6.3 on a 64-bit virtual machine (at the GCC compile farm) using the opencsgtest program (doc/testing.txt) and a virtual framebuffer (Xvnc) and was also unable to reproduce the hang or the crash.

[hroncok]

are you on 32 bit or 64 bit?
64bit, currently on Intel.

Forcing Goldfeather makes the difference for me, it compiles without a hiccup. What that means? Never used the option before.

[hroncok]

This may be important (but I'm not sure).

OpenCSG build flags: -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -I/usr/lib64/qt4/mkspecs/linux-g++ -I. -I/usr/include -I../include -I.. -I/usr/X11R6/include

OpenSCAD build flags: -pipe -fno-strict-aliasing -frounding-math -DEIGEN_DONT_ALIGN -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O2 -D_REENTRANT -Wall -W -DOPENSCAD_VERSION=2012.10.31 -DOPENSCAD_YEAR=2012.0 -DOPENSCAD_MONTH=10.0 -DOPENSCAD_DAY=31.0 -DDEBUG -DUSE_PROGRESSWIDGET -DENABLE_CGAL -DENABLE_OPENCSG -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt4/mkspecs/linux-g++ -I. -I/usr/include/eigen2 -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtOpenGL -I/usr/include -Isrc -I/usr/X11R6/include -Iobjects -Iobjects

[donbright]

hroncok: OpenCSG allows the user to choose which algorithm to use during rendering - one is Goldfeather and one is SCS. Each algorithm uses OpenGL differently so if there are bugs or glitches somewhere in the OpenGL pipeline, (hardware, driver, OS, libraries, maybe even OpenCSG) sometimes one algorithm will trigger the issue while the other won't.

Marius added the option to force Goldfeather, if I remember correctly, as a workaround for some bugs involving some "Intel HD" graphics cards/drivers, see Issue #65 . It may also be related to Issue #198 which also manifests as different behavior depending on which algorithm is selected.

[hroncok]

Just to let you know, issue's reproducable in the latest version.

[donbright]

Thanks for the update. Does the goldfeather workaround still work for you in the latest version?

[hroncok]

Yes, it does.

[hroncok]

There is a terminal output before the crash in recent "version" (cannot remember, if it was present before):
openscad: brw_queryobj.c:278: brw_begin_query: Assertion `!"Unrecognized query target in brw_begin_query()"' failed.

[kintel]

One idea: We could build a pure OpenCSG app (e.g. the standard OpenCSG example), and check if we can isolate the problem without dragging in all of OpenSCAD. That could make this easier to debug.

[hroncok]

Well,
the most stripped code I can get to reprodce is this:

difference() {
    cube();
    render(convexity = 2) cube();
    for (i = [
        [ 0, 0, [ [0, 0], [0, 0] ] ],
        [ 0, 0, [ [0, 0], [0, 0], [0, 0], [0, 0], [0, 0] ] ],
        [ 0, 0, [ [0, 0], [0, 0], [0, 0], [0, 0], [0, 0] ] ],
        [ 0, 0, [ [0, 0], [0, 0], [0, 0] ] ],
        [ 0, 0, [ [0, 0], [0, 0], [0, 0], [0, 0] ] ]
    ]) {
            for (j = i[2]) cube();
    }
}

Works with any primitive solids or any numbers instead of zeros. Not quite sure how the [[[ hell ]]] is working, but if I remove just one part of it, it won't crash.

I am able to run the OpenCSG example, but have no idea, how to implement this into it, as I have no idea how to do this for with brackets in brackets in C++.

[kintel]

Does anyone know if this is reproducible in a VM (I've only got a Mac atm.)?

[donbright]

hroncok - would you be able to go into /help/Library Info/Details, and copy/paste everything under there to this thread?
I am very interested in what it says under "OpenGL Version". Thanks again for the bug reports.

[hroncok]

Does anyone know if this is reproducible in a VM (I've only got a Mac atm.)?

In Virtualbox, I am unable to reproduce. If I use 3D acceleration, I see nothing after the compilation and if I disable it, I see only some surfaces, as I think is described in other issue I cannot find right now. However, no crash.

I would like to provide some kind of remote access, but my current upload speed is not very good. However, There are some desktops at our lab at the university connected much better. I could try if the bug is reproducable there.

go into /help/Library Info/Details, and copy/paste everything under there to this thread?

Boost version: 1_50
Eigen version: 2.0.17
CGAL version: 4.0.2
OpenCSG version: OpenCSG 1.3.2

GLEW version 1.7.0
OpenGL version 2.1 Mesa 9.0.1
Mesa DRI Intel(R) Ivybridge Mobile  (Intel Open Source Technology Center)

RGBA(8880), depth(24), stencil(8)
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_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_NV_vertex_program 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_NV_vertex_program1_1 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_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_rectangle GL_EXT_pixel_buffer_object GL_EXT_texture_compression_rgtc GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample 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_EXT_timer_query 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_AMD_draw_buffers_blend GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_debug_output 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_seamless_cube_map GL_ARB_shader_texture_lod GL_ARB_texture_rgb10_a2ui GL_ARB_uniform_buffer_object GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_ARB_robustness GL_ARB_shader_bit_encoding GL_ARB_texture_storage GL_EXT_transform_feedback GL_ARB_invalidate_subdata 

I am very interested in what it says under "OpenGL Version".

Is 2.1 good or bad?

[donbright]

Thank you, technically OpenGL 2.1 should be fine but in reality drivers can crash. A google search of "Mesa intel i965 crash" leads to a large number of discussions. It is interesting to see the programmers on the Chromium project talk about 'blacklisting' Mesa Intel drivers.

http://code.google.com/p/chromium/issues/detail?id=164555
http://src.chromium.org/viewvc/chrome/trunk/deps/gpu/software_rendering_list/software_rendering_list.json?annotate=145802

So maybe it is a driver bug, but perhaps there is some way to do a 'workaround'...

Update: interesting article on i965 driver development.

http://www.phoronix.com/scan.php?page=news_item&px=MTI1MDQ

[kintel]

This is a Mesa bug:
http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri?id=e755c1a36b27d6e45f0ae81729908342b8775c74

Blacklisting certain known-to-be-buggy drivers might make sense - it just sucks to maintain.

[donbright]

I know what we can do. We can make an "OpenSCAD Compatible" badge.

Then NVidia, Intel, and AMD will be so desperate to have the badge, they will fix their drivers.

[hroncok]

:D

[hroncok]

This is a Mesa bug:

I probably don't understand the linked patch'es code. Is this the fix or a proof of a Mesa bug?

Thanks.

[kintel]

It looks like the link is to the actual bugfix. I don't have the hardware in questions available, so I cannot test that this fixes the issue.

[kintel]

Closing as it was a Mesa bug