gnome-inform spurious crashes miracuously fixed

Hope this is the right place to report this, but gnome-inform, the IDE for inform on linux, used to once in a while crash when I pressed the compile-and-run button. It used to be abit annoying, and I never reported it, because I assumed it was just a buggy program (sorry!) - now it seems that was not entirely just…

My reporting here is maybe to help gnome-inform development, but also, to notify if there are others with a similar issue, that here may be some things to try that may solve it. I changed some preferences, which were still mostly the default (except for some common extensions I had included previously). Preferences changes were, I believe, on the formatting tab: alternate fonts, font size, and the style; I probably also marked `compiler debugging’ in the advanced tab. And I now am happy to report the crashes haven’t occurred since!

It is a bit surprising, really, because the crashes used to occur most commonly, as said, after the compile-and-run - though not always maybe in 10% of the cases; and only if there was no error in my inform code. I know this because I saw the green Report on Translation: Succeeded' for a few seconds, It probably did someGenerating code’ in the progress background - and then, if you were unlucky, the crash.

Very often I saw this assertion failure on the commandline:
Gdk:ERROR:gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)

I once searched on google for this, and there was someone on stackoverflow with seemingly something similar:
stackoverflow.com/questions/946 … vice-async
which led me to believe it was due to the usage of some deprecated gtk functions or so - but I never was able to find any of the culprit function calls in your gnome-infom C++ code.

Another way that I was certain to trigger a crash was by, In the extensions tab, going to its documentation and do a document text search (top right input bar). This didn’t happen in the normal documentations though, only when on the extensions tab.

I also used to see some warnings on the console:
(gnome-inform7:6778): Gtk-WARNING **: Unknown tag `indent-N’
where N was usually 1 or 2, but sometimes up to 5.

Maybe it is a font issue? a missing font, that triggers it? That could explain why changing the fonts may have solved it.
See attached for one entire trace.I often see fonts (the lines ending with .ttf), and then the (deleted) between them, which may be a dereferencing of a invalid or freed pointer issue?

I saw these, at least (from three different crashes)

Error in gnome-inform7': realloc(): invalid pointer: 0x0000559626238ac0 *** Error ingnome-inform7’: free(): invalid pointer: 0x00005579bfe1e320 ***
*** Error in `gnome-inform7’: realloc(): invalid pointer: 0x0000561a3fb08e70 ***

the platform is:
Linux Z 4.10.13-1-ARCH #1 SMP PREEMPT Thu Apr 27 12:15:09 CEST 2017 x86_64 GNU/Linux
gnome-inform_advanced-tab.png
gnome-inform_formatting-tab.png
gnome-inform-crash.txt (22.9 KB)

i’ve also experienced a problem consistent with everything you said in this post, so this is useful to me! do you think you could post a screenshot of the section of the preferences that you believe is relevant, or otherwise list the values you set?

Added. Not sure if step 5 & 6 are necessary. And the proggyClean font may not be standard installed. But then I think just selecting any font that exists on the system may help the issues go away.

Though the crashes were gone for a while, it seems that gnome-inform still does crash sometimes. I’ve tried to change the settings again as in the screenshots - to see if that had induced a temporary effect - but that seems not to stop the returned crashes.

There still are some differences though: I no longer get the long stack traces. Also I still do not reproduce the trigger I reported, which was there on first instance; searching on the extensions tab. I always seem to get them after a (sorta succesful) compile-and-run. What I did observe on the commandline of the last few crashes was:

[code]Z:~$ gnome-inform7
** Message: console message: file:///usr/share/gnome-inform7/Documentation/doc50.html#defn4 @31: TypeError: null is not an object (evaluating ‘document.getElementById(id).style’)

** Message: console message: file:///usr/share/gnome-inform7/Documentation/doc50.html#defn4 @31: TypeError: null is not an object (evaluating ‘document.getElementById(id).style’)

** Message: console message: file:///usr/share/gnome-inform7/Documentation/doc50.html#defn4 @31: TypeError: null is not an object (evaluating ‘document.getElementById(id).style’)

**
Gdk:ERROR:gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)
**
Gdk:ERROR:gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)
Aborted (core dumped)
Z:~$ gnome-inform7
**
Gdk:ERROR:gdkregion-generic.c:1123:miUnionNonO: assertion failed: (pReg->numRects<=pReg->size)
**
Gdk:ERROR:gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)
Aborted (core dumped)
Z:~$ gnome-inform7
**
Gdk:ERROR:gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)
Aborted (core dumped)
Z:~$ gnome-inform7
gnome-inform7: hb-object-private.hh:160: Type* hb_object_reference(Type*) [with Type = hb_face_t]: Assertion `hb_object_is_valid (obj)’ failed.
Aborted (core dumped)
Z:~$ gnome-inform7
**
Gdk:ERROR:gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)
Aborted (core dumped)[/code]

I greatly appreciate people actually troubleshooting this, rather than saying “It doesn’t work!” and dropping the Gnome version altogether in aggravation. The linux IDE is my favorite version.

I’m not completely sure but I was having more at-compile crashes today and then I switched to GIT and it seems to work better. I’m not sure if that was the fix or something else, though.

Switched to the git version now. I tried doing some debugging, running gnome-inform7 with gdb and valgrind. Valgrind reports a lot of possibly/definitely lost blocks, but it is not clear exactly where they originate from in the gi7 code. There’s this one that may be of interest.

==7404== Conditional jump or move depends on uninitialised value(s) ==7404== at 0xAEEBEFE: ??? (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0xAEEA643: g_param_value_validate (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0xAEE669A: g_object_set_valist (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0x83EEE16: goo_canvas_path_model_new (in /usr/lib/libgoocanvas.so.3.5.0) ==7404== by 0x149DE0: i7_node_init (node.c:333) ==7404== by 0xAF0235A: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0xAEE41FA: ??? (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0xAEE610D: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0xAEE63B0: g_object_new (in /usr/lib/libgobject-2.0.so.0.5200.1) ==7404== by 0x14A414: i7_node_new (node.c:522) ==7404== by 0x154787: i7_skein_init (skein.c:143) ==7404== by 0xAF0235A: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.5200.1)

But what variable could be unitialized?
i7_skein_init() on skein143 calls with fixed variables, and i7_node_new() passes most of them to g_object_new(), ok there’s an underscore macro, but I’m guessing that’s just a translation stub?
Not exactly sure how this works, but it seems that in i7_node_class_init() properties are defined that are not included: “blessed” and “match”. The order is also different.

Another option: in i7_node_init() 333: is the visibility property allowed?
I do not see it mentioned here:
https://developer.gnome.org/goocanvas/stable/GooCanvasPathModel.html