GNOME Bugzilla – Bug 652391
g-ir-compiler segfault
Last modified: 2018-01-25 16:12:43 UTC
While building sqlheavy from git, the following command causes a segfault: LD_LIBRARY_PATH=.libs /usr/bin/g-ir-compiler --includedir=. --includedir=. --shared-library=sqlheavy0.1 SQLHeavy-0.1.gir -o SQLHeavy-0.1.typelib & sqlheavy git repo: http://gitorious.org/sqlheavy The segfault is caused either by 99313967 or a985c883, previous checkouts work fine. Shouldn't g-ir-compiler abort on error instead of entering an infinite recursion and segfaulting? gdb backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00007f651866c1ab in vfprintf () from /lib/libc.so.6 (gdb) bt
+ Trace 227448
The backtrace has over 35000 levels (at least that's where I stopped pressing return). kernel.log: [ 5750.495752] g-ir-compiler[11877]: segfault at 7fff71ee3f18 ip 00007fd1720e51ab sp 00007fff71ee3f20 error 6 in libc-2.14.so[7fd1720a1000+157000]
Looks like this is due to SQLHeavy-0.1.gir containing an <include name="SQLHeavy" version="0.1"/>. It might be nice for g-ir-compiler to check for this type of issue, but the real problem seems valac (at least the 0.12 branch) generating an invalid GIR.
Created attachment 203515 [details] GIR files that doesn't compile with g-ir-compiler In this examples, you have the Gda-5.0.gir and GdaData-5.0.gir files, the first one is created with g-ir-scanner from sources in libgda. The second, is created from Vala sources using valac. Inspecting the first lines in GdaData-5.0.gir you can see that the following line is missing: <include name="Gee" version="0.8"/> when you try to compile to typelib using: g-ir-compiler --includedir=./ GdaData-5.0.gir --output GdaData-5.0.typelib Fails with a segfault. If you add that missing line (with gee-0.8.gir installed in your system) the compilation succeed. I think g-ir-compiler must check first that a symbol definition is missing instead to segfault.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Closing as obsolete. This should really be a bug in Vala, but given the age of the issue, I'm going to assume Vala has also been fixed not to generate invalid introspection data.