Bug 373614 - Crashes if Kdevelop is compiled against llvm 3.8 and mesa against 3.9
Summary: Crashes if Kdevelop is compiled against llvm 3.8 and mesa against 3.9
Status: RESOLVED DOWNSTREAM
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: 5.0.1
Platform: Debian testing Linux
: VHI crash
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL: https://bugs.debian.org/cgi-bin/bugre...
Keywords:
: 373127 373525 375892 382334 398243 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-13 14:23 UTC by Lisandro Damián Nicanor Pérez Meyer
Modified: 2018-09-04 21:19 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lisandro Damián Nicanor Pérez Meyer 2016-12-13 14:23:52 UTC
Original bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846410

We have Kdevelop compiled against LLVM-3.8. Some users started detecting that if their mesa drivers get compiled against LLVM-3.9 this last version will get loaded first and Kdevelop will crash at loading a project.

You can find a backtrace at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846410#5>

You can also check that the crash dissapears if a non-llvm-3.9 video driver is loaded at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846410#84>.
Comment 1 Kevin Funk 2016-12-13 19:48:07 UTC
*** Bug 373525 has been marked as a duplicate of this bug. ***
Comment 2 Kevin Funk 2016-12-13 19:48:46 UTC
*** Bug 373127 has been marked as a duplicate of this bug. ***
Comment 3 bomox 2017-02-02 12:13:28 UTC
*** Bug 375892 has been marked as a duplicate of this bug. ***
Comment 4 Roman Gilg 2017-03-21 14:24:38 UTC
It's really unfortunate, that this bug still persists even after several months now and with a new point release just out now!

Solving this bug should have the highest priority right now! People who need to use the latest mesa drivers (like me) aren't able to use KDevelop for a prolonged time now.
Comment 5 Kevin Funk 2017-03-21 14:28:41 UTC
Sorry, Roman, unfortunately there's no easy fix for this problem.

If someone's got a good solution for this problem, without having us use libclang out of process, I'm all ears.
Comment 6 Lisandro Damián Nicanor Pérez Meyer 2017-03-21 15:16:27 UTC
The *real* fix should come from LLVM itself by adding versioned symbols.

This has happened for Debian a day or two ago, maybe this experience can be pushed upstream.
Comment 7 Roman Gilg 2017-03-21 15:34:00 UTC
Thanks for your responses! What would be the right way to bring it to their attention?

Can you link to what you mean by "happened for Debian a day or two ago"?

I assume an intermediate solution to get KDevelop going again in the meantime is not possible or difficult as Kevin said.
Comment 8 Kevin Funk 2017-03-21 15:34:41 UTC
@Lisandro: Wow, that's awesome to hear! Would love to learn more about it, too. Maybe send a mail to kdevelop-devel@kde.org?
Comment 9 Roman Gilg 2017-05-06 15:11:19 UTC
Is this bug fixed? I just tried KDevelop out again and it didn't crash.
Comment 10 Lisandro Damián Nicanor Pérez Meyer 2017-06-23 14:31:10 UTC
The Debian fix (and actually the right one) was to add ELF symbols versions to LLVM, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849098>

Sorry for the late reply.

@Kevin please tell me if you still want the mail, but the fix should really happen in LLVM upstream or make distros carry a delta like we do now...
Comment 11 Kevin Funk 2017-06-23 15:00:35 UTC
Could you point me to the patch(es)?
Comment 13 Kevin Funk 2017-07-14 12:27:17 UTC
*** Bug 382334 has been marked as a duplicate of this bug. ***
Comment 14 RJVB 2017-07-14 14:13:15 UTC
Has this been reported upstream? I just saw the issue with swrast loading the library from Ubuntu's llvm-toolchain-3.8 (dated June 29th 2017) while kdev-clang uses LLVM 4.0 from llvm.org (1:4.0~svn305187-1~exp1 from June 15th or so).

And: do both libLLVM copies involved need to carry the patch or is it enough if one of them does?


As I reported in my #382334, I have been able to work around the crash by making mesa's libLLVM a symlink to the one used by kdev-clang, for now without side-effects. YMMV, this may only be possible if the latter is newer than the former, for instance (that would apply to Qt libraries, for instance).
Comment 15 Kevin Funk 2017-08-07 09:52:09 UTC
> Has this been reported upstream? 

I don't think it has yet, unfortunately. I'm going to discuss this on the LLVM mailing list as soon as possible.

> And: do both libLLVM copies involved need to carry the patch or is it enough if one of them does?

I'd presume if only one of the libLLVM copies carries the patch, that'd be enough.
Comment 16 Kevin Funk 2017-08-07 21:21:00 UTC
Actually, there's already a patch (approved & merged) upstream which I forgot about:
  https://reviews.llvm.org/D31524

Thanks to Lisandro et al.

@Lisandro: I think we can consider this fixed, correct? At least from our side, there's nothing else to -- upstream distros need to patch their LLVM copies.
Comment 17 RJVB 2017-08-07 22:08:21 UTC
I'm not holding my breath for them to backport this patch to older LLVM versions like 3.8 ...
Comment 18 Lisandro Damián Nicanor Pérez Meyer 2017-08-08 13:17:45 UTC
(In reply to Kevin Funk from comment #16)
[snip] 
> @Lisandro: I think we can consider this fixed, correct? At least from our
> side, there's nothing else to -- upstream distros need to patch their LLVM
> copies.

Indeed, this is the way to go. I'm *really* glad this went this far :-)
Comment 20 Kevin Funk 2018-09-04 16:24:48 UTC
*** Bug 398243 has been marked as a duplicate of this bug. ***
Comment 21 RJVB 2018-09-04 17:02:59 UTC
There is a rather evident workaround (which I ended up applying myself). The Mesa culprit is the (gallium) LLVM-accelerated software rasteriser (swrast). I think this is typically used only for OpenGL operations on a remote display, but Mesa also comes with (or can be built to provide) a non-accelerated version. Remove or uninstall the accelerated driver or rebuild Mesa (with --disable-gallium-llvm --disable-gallium-llvm) and the problem goes away.
With a reasonably modern CPU you shouldn't notice much of performance drop in the desktop eye candy that uses OpenGL.

Sorry that I cannot be more specific, I did this months ago and didn't take note exactly how. It seems I simply rebuilt Mesa without the gallium-llvm stuff in a launchpad PPA.
Comment 22 RJVB 2018-09-04 17:04:12 UTC
(Of course, if you rebuild Mesa locally you can just as well make it use the same LLVM as KDevelop uses, in particular if it has the aforementioned patch...)
Comment 23 Jan Kriho 2018-09-04 20:10:43 UTC
(In reply to RJVB from comment #21)

This is not viable, because the LLVM swrast isn't the only rasteriser using LLVM. It is used also in R600 and RadeonSI Mesa drivers
Comment 24 RJVB 2018-09-04 21:19:49 UTC
Disabling LLVM support in mesa with --disable-gallium-llvm indeed prevents building some other drivers (the R300 and R600 at least).

Whether that's acceptable depends on the hardware you're using. For me it is perfectly fine :)