Bug 59334

Summary:	Automake Regression - Clover: Assertion failures when loading pipe_r600.so driver
Product:	Mesa	Reporter:	Tom Stellard <tstellar>
Component:	Other	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	59304
Attachments:	Work around for bug

Description Tom Stellard 2013-01-14 03:07:21 UTC

With r600g I'm seeing the following assertion failure when I try to run any OpenCL programs:

hello_world: /home/tstellar/llvm/include/llvm/Support/CommandLine.h:646: void llvm::cl::per<DataType>::addLiteralOption(const char*, const DT&, const char*) [with DT = llvm::ScheeDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level), DataType = llvm::ScheeDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)]: Assertion `findOptioame) == Values.size() && "Option already exists!"' failed.

This assertion failure appears to be caused by static objects that are initialized more than once.  The first initialization comes from within clover and the second comes from the pipe_*.so driver when clover loads it.

The backtrace for this assertion failure starts with: _GLOBAL__sub_I_SelectionDAGISel.cpp 

If I run:
objdump -t libOpenCL.so.1.0.0

I can see that this symbol is included in the libOpenCL.so.1.0.0 library after the automake changes were merged, but it was not included before the merge.

This bug likely also affects the EGL state_tracker with r600g or radeonsi.

I will do my best to bisect and see which commit caused this bug, but I'm not sure if bisection through the automake changes is possible.

Comment 1 Tom Stellard 2013-01-14 15:53:11 UTC

After bisecting, it looks like I introduced this error on clover with this commit:

commit 4148a29ed83d1d85bff3d4e40e847128011c3f20
Author: Tom Stellard <thomas.stellard@amd.com>
Date:   Fri Jan 11 17:28:35 2013 +0000

    targets/opencl: Link against libgallium.la instead of libgallium.a


I can confirm that the EGL state tracker suffers from a similar problem, and I'm going to bisect to try to determine the cause of it.

Comment 2 Michel Dänzer 2013-01-14 16:26:39 UTC

Although I did see the "Option already exists!" failure with EGL with one of the last automake branches before the merge, I'm not seeing it (or any other LLVM related failure) now.

Comment 3 Tom Stellard 2013-01-14 17:47:24 UTC

Created attachment 73013 [details]
Work around for bug

This patch works around the bug by linking against libgallium.a rather than libgallium.la.  However, this is not a good solution and we should continue to look for a better one.

Comment 4 Tom Stellard 2013-01-17 22:10:16 UTC

(In reply to comment #3)
> Created attachment 73013 [details]
> Work around for bug
> 
> This patch works around the bug by linking against libgallium.a rather than
> libgallium.la.  However, this is not a good solution and we should continue
> to look for a better one.

I've hit this bug again.  However, this time the assertion fails when a second pipe_*.so is loaded by libOpenCL.so, so these static objects are no longer being initialized by libOpenCL.so, but they are being initialized by each pipe_*.so that is loaded.  It seems like the problem might be the visibility of symbols in libOpenCL.so

Comment 5 Tom Stellard 2013-01-24 16:10:30 UTC

Fixed by commit cf69a591e1ad16b590c9ae2eba0da6fa6c4fc741

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.