core dumping at exit

[uncleyear]

Currently jucipp(version 1.3.0) dumps core at exit on FreeBSD 11.1 in case any open window exists or, alternatively, window was opened(new file or existing doesn't matter) and closed . Since i am not familiar with GTK+ the only information about crash that may be helpful is a stack trace. Suspicious(very) place is double call to dtor Gsv::LanguageManager::~LanguageManager with the same this pointer. bt.txt

[eidheim]

Thank you for reporting this, and for the stack backtrace. I'll have a look after installing FreeBSD in a VirtualBox.

It seems like a gtksourceviewmm3 bug to me, but I'll try and see if creating only one Gsv::LanguageManager::get_default() instance works as a workaround. Alternatively, I'll use the C API instead.

edit: changed Gsv to gtksourceviewmm3

[eidheim]

What version of gtksourceviewmm3 do you have? My FreeBSD got 3.2.0 which is really old.

[eidheim]

I think the solution here is to upgrade the gtksourceviewmm3 package on FreeBSD (https://svnweb.freebsd.org/ports/head/x11-toolkits/gtksourceviewmm3/). It is actually surprising that jucipp compiles at all with this old gtksourceviewmm3 version. I'll mark this issue solved and help-wanted for now.

[uncleyear]

Yes, the version of gtksourceviewmm3 on FreeBSD is currently 3.2.0. Rather old, indeed, but it is still thin wrapper above main library gtksourceview. In my opinion it shoudn't be surprising since API is still "number 3" and this is "a good thing". Anyway, thanks for such interesting light editor/ide for developing.

[uncleyear]

IMHO, there is a tension(race condition and reliance on UB) between gtksourceview and glibmm libraries and this situation with crash have emerged in my environment. It seems to me that gtksourceview should be fixed to solve this. The quick and easy fix to this for a jucipp is just to replace calls to get_default() method of Gsv::LanguageManager and Gsv::StyleSchemeManager classes in a source.cc.

[eidheim]

Did you try to manually upgrade your gtksourceviewmm3 library? I tried a little bit, but never got its build system to configure. I'm new to FreeBSD though, so probably did not do things correctly.

You can download the latest gtksourceviewmm versions here: https://download.gnome.org/sources/gtksourceviewmm/

[uncleyear]

It is not gtksourceviewmm3, it is gtksourceview3 library where problem is(again, IMHO). And what i checked is version of this library up to 3.24.5 that is of Oct 1 2017, although i have version 3.22.2. And, btw, what version of gtksourceview3 library is used in your system?

++ In FreeBSD there is a new pkg system now to use binary software packages. I am still using ports system to build software from sources. There is good intro on their site - https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html. And if you are still interested i can help.

[uncleyear]

Should note that there is a high chance that this situation gone with newer versions of glibmm(that pulls new sigc++ and, as i understand, breaks some abi), although i did not test it. So, i do not expect that these ports will be updated soon but who knows. But, nevertheless, in the current FreeBSD environment(and may be on some other platforms) crashing chances are possible and solution is as i said earlier to use create() methot instead of get_default(). (In a few words, in the current situation with used versions of given ports in FreeBSD there is a race between global static objects and library destructors.)

[eidheim]

Thanks a lot for looking into this. I managed to compile and install version 3.18 of gtksourceviewmm and you are right, it did not solve the problem (I build/compiled and installed through the FreeBSD ports).

Out of curiosity, do you know what the undefined behavior that you refer to is? Is the problem both in our versions of gtksourceview and glibmm, or glibmm only?

I'll look into using create() instead of get_default(), maybe add a glibmm version check and use get_default() if the version is known to work correctly. In that case, I would have to know which glibmm version fixes the issue.

[uncleyear]

The problem lies in a cooperative running of these two libraries. In the glibmm library global static mutex(extra_object_base_datamutex in objectbase.h) is used(used until version 2.51.1.1, IIRC). In the gtksourceview library global library "ctors"/"dtors" are used(see gtksourceview-init.c). In case the default language manager exists some cleanup functions are called. But, according to this link https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes, order of calling static objects's ctor/dtor and functions registered with compiler attributes "__attribute_\((constructor))"(and destructor respectively) is unspecified. So, in my case, global static mutex's destructor was called before the gtksourceview library's "destructor" and access to destroyed mutex was causing crash. Again, here crash was possible since we are using gtksourceviewmm library above gtksourceview and it uses glibmm. Many words but hope it is more or less clear now.

[eidheim]

Thank you again for the excellent writeup and for researching this issue to such a great extent. The above commit is based on your suggested fix, and I have verified that it solves the core dump in FreeBSD. I installed all the libraries through pkg, and compiled jucipp manually. My glibmm version is 2.50.1.