After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768817 - libvala makes GNOME Builder unstable
libvala makes GNOME Builder unstable
Product: vala
Classification: Core
Component: Semantic Analyzer
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on: 712694 757840
Reported: 2016-07-14 19:13 UTC by Daniel Espinosa
Modified: 2018-05-22 15:37 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Daniel Espinosa 2016-07-14 19:13:03 UTC
libvala is used by GNOME Builder to provide syntax analysis, but constantly cash when source code is re-analysed.

I've haven't but Christian Herbert in Bug #757840, reports memory hungry and frequent crashing.

This bug could go in two directions or both:

1) Add documentation to libvala in order to reduce potencial crashing due to incorrect or misunderstanding use.

2) Fix libvala to improve its usefulness to other projects, including avoid crashing
Comment 1 Daniel Espinosa 2016-07-14 19:14:00 UTC
 Making depends on Bug #757840, as a test bed for improvements.
Comment 2 Christian Hergert 2016-07-14 23:21:25 UTC
I would like to see stuff move out of process in general, so I don't think we necessarily have to "fix libvala to be crash safe". That is a really hard thing to do in a compiler.

Compilers in general are notorious for both leaking and causing a great deal of memory fragmentation. By moving them out of process we can handle both of those as normal operating procedure.

This will have implications on how we design for IPC. Ideally we will be moving large, contiguous memory chunks around (such as a large GVariant). This is useful for things like the highlight index, autocompletion results, etc. We go through a lot of them in little time, so having a large contiguous memory chunk allows less pressure on the allocator, while also allowing for GVariant sub-slices efficiently.

When we redo the completion engine, we'll probably start relying on GVariant for just this purpose (with the intention of moving everything out of the UI process).

My hope is that we can keep Builder's UI memory footprint rather small and well contained, while the subprocesses get recycled as needed (and use cgroups to enforce mem/cpu/etc).
Comment 3 GNOME Infrastructure Team 2018-05-22 15:37:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: