llvm dev - Feb 2015 - [LLVMdev] Segfault when using llvm-3.6 and OpenGL at the same time on Linux (with mesa, which uses llvm-3.4)

2015-02-17 15:59 GMT+01:00 Tom Stellard <tom at stellard.net>:
> On Mon, Feb 16, 2015 at 10:38:52PM +0100, Daniel Albuschat wrote:
> > Hello there,
> >
> > tl;dr:
> > Is it a known behaviour that using llvm-3.4 and llvm-3.6 at the same
time
> > in the same process (while llvm-3.6 is used from a linked shared
library
> > and llvm-3.4 is dlopen'ed - with a strange detail: Especially if
> -rdynamic
> > is used when linking the program).
> > If so, is there a workaround?
> > If not, can it be fixed in llvm-3.6?
>
> The NVIDIA proprietary driver does not use mesa at all.  Also based on
> your backtrace, you are using llvmpipe and not nouveau.
>
Yeah, the backtrace was created from within VirtualBox. That driver, and
the nouveau driver, cause the same issue. The VMWare driver, too.

> I'm not a linking expert, but I have seen and fixed a few of these
issues
> with Mesa.  In most cases the fix is to make sure that the llvm symbols
> in the mesa driver and also the llvm symbols in your application aren't
> being exported as global symbols.

How do I have control about how llvm symbols are being exported?

nm reports no exported symbols matching llvm:

daniel at ubuntu32-dev:~/projects/llvmcrash$ nm libcrashme.so | grep llvm
         U _ZN4llvm11LLVMContextC1Ev
         U _ZN4llvm11LLVMContextD1Ev

Thanks!
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/992db1a7/attachment.html>

On Tue, Feb 17, 2015 at 08:15:09PM +0100, Daniel Albuschat
wrote:
> 2015-02-17 15:59 GMT+01:00 Tom Stellard <tom at stellard.net>:
> 
> > On Mon, Feb 16, 2015 at 10:38:52PM +0100, Daniel Albuschat wrote:
> > > Hello there,
> > >
> > > tl;dr:
> > > Is it a known behaviour that using llvm-3.4 and llvm-3.6 at the
same time
> > > in the same process (while llvm-3.6 is used from a linked shared
library
> > > and llvm-3.4 is dlopen'ed - with a strange detail: Especially
if
> > -rdynamic
> > > is used when linking the program).
> > > If so, is there a workaround?
> > > If not, can it be fixed in llvm-3.6?
> >
> > The NVIDIA proprietary driver does not use mesa at all.  Also based on
> > your backtrace, you are using llvmpipe and not nouveau.
> >
> 
> Yeah, the backtrace was created from within VirtualBox. That driver, and
> the nouveau driver, cause the same issue. The VMWare driver, too.
> 
> 
> > I'm not a linking expert, but I have seen and fixed a few of these
issues
> > with Mesa.  In most cases the fix is to make sure that the llvm
symbols
> > in the mesa driver and also the llvm symbols in your application
aren't
> > being exported as global symbols.
> 
> 
> How do I have control about how llvm symbols are being exported?
> 
Mesa uses linker scripts to control this.
> nm reports no exported symbols matching llvm:
> 
> daniel at ubuntu32-dev:~/projects/llvmcrash$ nm libcrashme.so | grep llvm
>          U _ZN4llvm11LLVMContextC1Ev
>          U _ZN4llvm11LLVMContextD1Ev
> 
What about swrast_dri.so from Mesa?

-Tom
> Thanks!
> Daniel

2015-02-17 20:49 GMT+01:00 Tom Stellard <tom at stellard.net>:
> On Tue, Feb 17, 2015 at 08:15:09PM +0100, Daniel Albuschat wrote:
> > 2015-02-17 15:59 GMT+01:00 Tom Stellard <tom at stellard.net>:
> >
> > > On Mon, Feb 16, 2015 at 10:38:52PM +0100, Daniel Albuschat wrote:
> > > > Hello there,
> > > >
> > > > tl;dr:
> > > > Is it a known behaviour that using llvm-3.4 and llvm-3.6 at
the same
> time
> > > > in the same process (while llvm-3.6 is used from a linked
shared
> library
> > > > and llvm-3.4 is dlopen'ed - with a strange detail:
Especially if
> > > -rdynamic
> > > > is used when linking the program).
> > > > If so, is there a workaround?
> > > > If not, can it be fixed in llvm-3.6?
> > >
> > > The NVIDIA proprietary driver does not use mesa at all.  Also
based on
> > > your backtrace, you are using llvmpipe and not nouveau.
> > >
> >
> > Yeah, the backtrace was created from within VirtualBox. That driver,
and
> > the nouveau driver, cause the same issue. The VMWare driver, too.
> >
> >
> > > I'm not a linking expert, but I have seen and fixed a few of
these
> issues
> > > with Mesa.  In most cases the fix is to make sure that the llvm
symbols
> > > in the mesa driver and also the llvm symbols in your application
aren't
> > > being exported as global symbols.
> >
> >
> > How do I have control about how llvm symbols are being exported?
>
> Mesa uses linker scripts to control this.
>
> > nm reports no exported symbols matching llvm:
> >
> > daniel at ubuntu32-dev:~/projects/llvmcrash$ nm libcrashme.so | grep
llvm
> >          U _ZN4llvm11LLVMContextC1Ev
> >          U _ZN4llvm11LLVMContextD1Ev
>
> What about swrast_dri.so from Mesa?

No llvm symbols, either:

daniel at ubuntu32-dev:~/projects/omni2/cbuild$ nm -DC
/usr/lib/i386-linux-gnu/dri/swrast_dri.so | grep llvm
         U draw_create_no_llvm
         U draw_get_shader_param_no_llvm

I'm out of ideas now... can I somehow log the pathes of libraries loaded in
a process? Maybe I can find out whether llvm-3.4 loads some llvm-3.5
libraries or so. On the other hand, why would that only happen when
llvm-3.5 is actually used? Shouldn't it solely depend on PATH /
LD_LIBRARY_PATH which library is used?

It seems that dynamic libraries are far more complicated / far less
straight forward on Linux than I thought...

Greetings,
Daniel Albuschat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/dfdfe552/attachment.html>