Bug 98595

*** This bug has been marked as a duplicate of bug 98592 ***

For some reason, OpenBSD things symbol_table_entry has a non-trivial destructor and calls ralloc_set_destructor. However, it doesn't have a non-trivial destructor. This looks like a C++ compiler bug.

I can't say that this is a duplicate of bug 98592, which was fixed for intel hardware on linux.

It's not a duplicated of that bug.

This bug is different. It looks like the HAS_TRIVIAL_DESTRUCTOR macro isn't done correctly on OpenBSD.

Indeed the abort is not triggered with gcc 4.9 but is with gcc 4.2.1.

For gcc < 4.4.3 and for clang HAS_TRIVIAL_DESTRUCTOR is set to __has_trivial_destructor(T) otherwise it is (false).

Everything worked last weeked, though that was before cc6aa1d161280f10ded7834d1ec2413bc97589fe.

(In reply to Jonathan Gray from comment #5)
> Indeed the abort is not triggered with gcc 4.9 but is with gcc 4.2.1.
> 
> For gcc < 4.4.3 and for clang HAS_TRIVIAL_DESTRUCTOR is set to
> __has_trivial_destructor(T) otherwise it is (false).
> 
> Everything worked last weeked, though that was before
> cc6aa1d161280f10ded7834d1ec2413bc97589fe.

Did you bisect to that commit? Besides me jumping the gun (sorry about that) and marking this a duplicate of a bug caused by that change it doesn't look like it should have anything to do with this bug.

More likely to do will the linear allocator changes that landed 6 days ago. e.g 
23e373eb4f9ca374313306701890642c30e8877e

Sorry that commit was just looking over commits.  An actual bisect results in
"a4a93103fb8f5c21c4cd17e89f07badfab14c0ab is the first bad commit".

glsl: use the linear allocator for ast_node and derived classes

FYI: I'm seeing the same assertion/regression with Visual Studio.

Created attachment 127868 [details] [review]
proposed fix (or work-around)

This fixes things for me with MSVC.  I'm not 100% sure if there's any negative side-effects since I'm still learning my way through ralloc and the new linear allocator.

Comments?

I pushed 5b92008ae279962dc09bcf98c9e5511a325a2bd9, which is a tweaked version of George Kyriazis's patch.  He says he has a v2 patch.  And since this is still broken with older gcc, I'm leaving this open for now.

The proposed fix stops the assertion for me.

With i965 I now hit a different problem that seems to be unrelated, the (OpenBSD) kernel logs
error: [drm:pid19649:i915_context_is_banned] *ERROR* context hanging too fast, declaring banned!

Running Xorg with softpipe is fine though.

(In reply to Jonathan Gray from comment #11)
> The proposed fix stops the assertion for me.
> 
> With i965 I now hit a different problem that seems to be unrelated, the
> (OpenBSD) kernel logs
> error: [drm:pid19649:i915_context_is_banned] *ERROR* context hanging too
> fast, declaring banned!
> 
> Running Xorg with softpipe is fine though.

If it's an unrelated issue, please create a new bug report and close this one.  Thanks.

The "proposed fix" patch attached here does not seem to have been applied to master yet?

(In reply to Jonathan Gray from comment #13)
> The "proposed fix" patch attached here does not seem to have been applied to
> master yet?

A different, better fix was committed and that fixed the assertion.

It remains broken here with latest master (a456ea17fb460a68e28c13dd4b7086dc4309f410).  Is the fix you are referring to the commit related to microsoft compilers or a different one?

Starting program: /usr/X11R6/bin/glxgears 
assertion "info->canary == CANARY" failed: file "ralloc.c", line 84, function "get_header"

Program received signal SIGABRT, Aborted.
0x000002b372f3794a in thrkill () at <stdin>:2
2       <stdin>: No such file or directory.
        in <stdin>
Current language:  auto; currently asm
(gdb) bt
#0  0x000002b372f3794a in thrkill () at <stdin>:2
#1  0x000002b372f4a499 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2  0x000002b372f69d04 in *_libc___assert2 (file=Variable "file" is not available.
) at /usr/src/lib/libc/gen/assert.c:52
#3  0x000002b32df6e9e5 in get_header (ptr=Variable "ptr" is not available.
) at ralloc.c:84
#4  0x000002b32df6e9fd in ralloc_set_destructor (ptr=Variable "ptr" is not available.
) at ralloc.c:347
#5  0x000002b32df42db6 in glsl_symbol_table::add_type (this=0x2b2f1c9b230, name=0x2b34faa4730 "void", 
    t=0x2b32e64b360) at glsl/glsl_symbol_table.cpp:30
#6  0x000002b32df1179a in _mesa_glsl_initialize_types (state=0x2b2d8467830) at glsl/builtin_types.cpp:270
#7  0x000002b32dcf5b00 in _mesa_get_fixed_func_fragment_program (ctx=0x2b34c248000)
    at main/ff_fragment_shader.cpp:1226
#8  0x000002b32dda5c95 in _mesa_update_state_locked (ctx=0x2b34c248000) at main/state.c:169
#9  0x000002b32dda5d95 in _mesa_update_state (ctx=0x2b34c248000) at main/state.c:497
#10 0x000002b32dcbaa80 in _mesa_Clear (mask=16640) at main/clear.c:172
#11 0x000002b0ba00192e in ?? () from /usr/X11R6/bin/glxgears
#12 0x000002b0ba00256d in ?? () from /usr/X11R6/bin/glxgears
#13 0x000002b0ba0007d2 in ?? () from /usr/X11R6/bin/glxgears
#14 0x0000000000000000 in ?? ()

Not sure how exactly things are supposed to behave if we have a C++ construct wrapped in extern "C".

Namely: shouldn't the DECLARE_ALLOC_CXX_OPERATORS_TEMPLATE macro be outside of the extern C wrapper ?

Macros are unaffected by extern "C".