Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000895Gnome Inform application[Core Inform] Relationspublic2012-03-25 20:372017-08-16 20:15
Assigned Topchimento 
Platformx86OSLinuxOS VersionAny
Product Version6G60 
Target VersionFixed in Version 
Summary0000895: Inform crashes when playing with relations and descriptions
DescriptionThis code will crash the Inform IDE (the whole thing, GUI and all). It isn't terribly reliable, but compiling many (and unfortunately, this is one where you really may need *many*) times in a row can induce it. The error message is similar enough each time that I'm pretty sure it's the same thing.

I'd really like to give you a shorter example, but I wouldn't know where to start pruning, since I have no idea what causes this.

I've observed this primarily while compiling for Glulx, but I also observed it at least once when compiling for the Z-machine (version 8). Switching between target platforms may or may not increase likelihood of it happening; my sample size is too small to tell.

Minimal Source Text To Reproduce

The cave is a room.
The player carries an openable closed container called a jar.

General affordance relates one description of things to various action names.
Affordance relates a thing (called T) to an action name (called A) when a description of things (called 
D) relates to A by the general affordance relation and T matches D.

The verb to generally afford (it generally affords, they generally afford, it is generally afforded, 
it is generally affording) implies the general affordance relation.
The verb to afford (it affords, they afford, it is afforded, it is affording) implies the affordance 

Before doing something to something which affords the action name part of the current action:
	Say "Great idea!" 
When play begins:
	Make openable closed containers afford the opening action.

To make (D - a description of things) afford (A - an action name):
	Now D generally affords A.
Test me with "open me / open jar"
Additional InformationGdk:ERROR:/build/buildd/gtk+2.0-2.24.6/gdk/gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)

The above error is followed by either of the following, frequently the first:
Segmentation fault

Here's other info:
$ uname -a
Linux odin 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

I don't have debugging symbols for Inform, so I can't usefully run it under gdb. I *could* run it under Valgrind, but as we discovered last time I tried to figure a crash out, Valgrind is way too slow for this sort of thing, at least on my machine (and besides, its output is excessively verbose).

I've used the Linux IDE for other things, and it simply doesn't do this as a matter of course, so I'm pretty sure the source text is relevant (i.e. my usual experience weakly counts as a control).

Side note: the TEST ME will reliably crash the Glulx VM (just the VM, not the IDE) but not the Z-machine VM (which, nonetheless, behaves incorrectly, failing to fire the Before rule for opening the jar). This is probably from bug 510, and doesn't deserve a separate bug (unless the asymmetry between Glulx and Z-machine itself counts as a bug, which I'm not sure that it does).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
EmacsUser (manager)
2012-03-28 23:56

Google seems to suggest that that assertion failure is related to a missing claim on the GDK lock.
zarf (developer)
2012-04-03 11:28

On the side note: does not look related to 510. The patch for 510 does not change the compiler output for this test case.
zarf (developer)
2012-04-03 11:34

Yeah, look at this:

! Routine to decide if affordance(t_0, t_1)
[ Relation_69
    t_0 ! Call parameter 'T' = object
    t_1 ! Call parameter 'A' = action name
    t_2 ! Local variable e.g. 'D' = description of things
  if (~~(t_0 ofclass K2_thing)) rfalse;
    return ((( RelationTest(Rel_Record_67, RELS_LOOKUP_ANY, t_1, RLANY_CAN_GET_X) )) && (( (t_2(-1,t_0)) )));

t_2 is never set, and so the VM winds up calling function address zero. The Z-machine silently allows this (is that spec?) but Glulx errors out. It's clearly bad code, anyhow.
EmacsUser (manager)
2012-04-03 15:25

Oh, I see. So we really have two bugs: a problem with relating descriptions and a problem where bad Glulx function calls bring down the IDE.
NYKevin (reporter)
2012-04-03 15:27

Last time I failed to retrieve a description via a convoluted phrase it *was* related to 510, so I assumed this was the same issue. Guess I was wrong.
zarf (developer)
2012-04-03 20:50

The IDE crash is seen at compile time, not run time, right?
NYKevin (reporter)
2012-04-04 09:50

Well, that's honestly hard to tell... It happens right after the success message from the compiler, and right before it switches to the "Game" tab, so there's a good chance that it's runtime, but its also possible that the compiler does something strange which only manifests later... I don't pretend to know what the "GDK lock" is, so I can't judge which is more likely.
EmacsUser (manager)
2012-04-06 13:37

Sorry for my confusion. I haven't yet been able to recreate the IDE crash, but I have split off 0000902.
EmacsUser (manager)
2012-04-06 15:35

Hmm, I have managed to get sundry segfaults from Chimara, but that's almost certainly a different bug.

If you don't mind answering a few questions, I'd appreciate it:

1. Did you build from source, or did you download the .deb?
2. How are you running the story (Go, Test Me, Replay? By keyboard, toolbar, menubar?) when you see the crash?
3. Could you try to provoke the crash under gdb and post a backtrace? It would be helpful even without debugging symbols.
NYKevin (reporter)
2012-04-07 20:24
edited on: 2012-04-07 20:36

1) I downloaded the deb.
2) Go via Ctrl+R (usually). I've yet to witness it via the Index (possibly for lack of trying)
3) [^]

Note that I have no debugging symbols, so the above backtrace is of limited usefulness.

By the way, I've started to observe this with other source texts, which means the above source code probably has nothing to do with the issue (sorry for being wrong about that); it is of course possible that there's some subtle commonality, but I find it unlikely. In particular, I was able to produce the above backtrace with completely different source code (which is too long to post; it includes an unpublished extension I've been working on anyway).

It should be noted that the new source text does not crash the VM, so the issues are probably unrelated.

After I captured the bt above, I did this (should've put it in the pastebin, but a bit late now):

(gdb) c
[Thread 0x7fff94dcb700 (LWP 5086) exited]
[Thread 0x7fffd79fd700 (LWP 4920) exited]
[Thread 0x7fffe7a1b700 (LWP 4919) exited]
[Thread 0x7fffe721a700 (LWP 4909) exited]
[Thread 0x7fff95872700 (LWP 4926) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

If there are too many or too few threads, that might be relevant.

pchimento (developer)
2012-06-21 01:24

That assertion failure is almost definitely a GDK locking error from Chimara. They happen in corner cases and are extremely hard to track down, so having a reproducible test case is very valuable to me. OK if I move this from Core Inform to Gnome Inform Application and assign to myself?
EmacsUser (manager)
2012-06-21 05:05

If that question is directed at me, by all means. I'm at quite the loss for how to hunt this one down.
pchimento (developer)
2012-06-21 06:57

Yeah, locking errors are elusive and machine-dependent. When it happens, the relevant information is often in one of the other threads that didn't crash. So if I can't reproduce it myself, then NYKevin, would you be willing to do some more debugging?
NYKevin (reporter)
2012-06-21 09:17

Yes, although I may not have an opportunity to do so for a while. I'll try to get back to you promptly, but I can't guarantee my schedule.
pchimento (developer)
2013-04-20 14:41

I haven't been able to reproduce this at all, sorry. NYKevin, would you be willing to try and reproduce it by running under a debugger?
NYKevin (reporter)
2013-05-21 12:00

I've gone through multiple OS reinstallations; I'm not sure that I'd have any better luck than you. But I'd be willing to try.
pchimento (developer)
2013-05-21 13:53

OK, just get back to me when and if you have time to try.
EmacsUser (manager)
2013-06-14 15:42

Not sure what the current status is, but I can now semi-reliably (roughly 1/12 of the time) reproduce this crash in a build with debug symbols under Ubuntu 13.04. Is there info I could usefully post here? (I have all threads' backtraces logged at [^] and have left the same gdb session open.)
pchimento (developer)
2013-06-15 08:14

Thanks!! There's one more thing that would be useful to find out from that GDB session: which widget is at 0xacdc10 (frames 10-12, thread 1). (if possible - its GType name and its place in the widget hierarchy.)

Or maybe there's a way to watch what other code modifies the two parameters of gdk_region_union() in frame 6? I'm not good enough at GDB to understand how I would go about watching memory addresses when I didn't know what they were yet.
EmacsUser (manager)
2013-06-15 11:33

Looks like 0xacdc10 is a GtkLabel and its path from root is I7Story / GtkVBox / GtkHPaned / I7Panel / GtkNotebook / GtkLabel; I've updated the gist.

Regarding your second paragraph, am I understanding correctly that the assertion failure means that at least one of those two region arguments was modified by another thread sometime between gdk_region_union's call and return, so the goal is to ask gdb if it can catch this happening?
pchimento (developer)
2013-06-15 11:38

Thanks. Interesting that this widget is not even inside the Chimara widget at all! As for the second paragraph, that is exactly what I meant. I'm not 100% sure that that's what the assertion failure means, but that's my conjecture.
EmacsUser (manager)
2013-06-15 13:23
edited on: 2013-06-15 15:34

I'm not convinced it's related, but I have so far seen a release of the GDK lock by a non-holding thread. A backtrace is at [^]

Edit: No, looking at it again, that was a debugging error on my part.

pchimento (developer)
2014-03-24 22:27

@EmacsUser Can you still reproduce this using the current master branch? I can't.
EmacsUser (manager)
2014-03-27 14:22

I can. See [^] for a backtrace off the current master. (I've also left this session open, in case there's anything more I can poke at. My gdb-fu hasn't been good enough to solve 0000895:0002096.)

The context is rather different this time; the trouble turned up in i7_story_run_compiler_output within finish_i6_compiler, which should answer 0000895:0001645. But note that the widget in question is the same as before.
pchimento (developer)
2014-03-27 14:29

Thanks very much! So it's likely not a problem with Chimara after all. That narrows it down, because there are far fewer places in the I7 GUI that use threads.
EmacsUser (manager)
2014-03-27 14:34

(BTW, compilation fails on glk_schannel_pause(schanid_t chan) and glk_schannel_unpause(schanid_t chan) in src/chimara/libchimara/schannel.c when GSTREAMER_SOUND is undefined. Looks like a couple of missing #ifdefs.)
neroden (reporter)
2017-08-16 19:49
edited on: 2017-08-16 23:30

I have been getting what looks like this bug very regularly, running the Debian package.


Basically, about every 5th to 10th time I hit the button to recompile and play the game, the IDE crashes. With the Gdk assertion error mentioned. It seems to happen after the build is done, since the Build directory is fully populated, during the attempt to run the story.

Followup: after finding this bug I have started to run with the "sync" option ( gnome-inform7 --sync ) and it doesn't seem to crash as often.

It just crashed again, though:

Gdk:ERROR:/build/gtk+2.0-1aCJs4/gtk+2.0-2.24.31/gdk/gdkregion-generic.c:1110:miUnionNonO: assertion failed: (y1 < y2)

- Issue History
Date Modified Username Field Change
2012-03-25 20:37 NYKevin New Issue
2012-03-28 23:56 EmacsUser Note Added: 0001627
2012-03-28 23:56 EmacsUser Status new => acknowledged
2012-04-03 11:28 zarf Note Added: 0001639
2012-04-03 11:34 zarf Note Added: 0001640
2012-04-03 15:25 EmacsUser Note Added: 0001642
2012-04-03 15:27 NYKevin Note Added: 0001643
2012-04-03 20:50 zarf Note Added: 0001645
2012-04-04 09:50 NYKevin Note Added: 0001646
2012-04-06 13:33 EmacsUser Issue cloned 0000902
2012-04-06 13:37 EmacsUser Note Added: 0001651
2012-04-06 15:35 EmacsUser Note Added: 0001652
2012-04-06 15:35 EmacsUser Status acknowledged => feedback
2012-04-07 20:24 NYKevin Note Added: 0001653
2012-04-07 20:24 NYKevin Status feedback => new
2012-04-07 20:32 NYKevin Note Edited: 0001653 View Revisions
2012-04-07 20:36 NYKevin Note Edited: 0001653 View Revisions
2012-06-21 01:24 pchimento Note Added: 0001694
2012-06-21 05:05 EmacsUser Note Added: 0001696
2012-06-21 06:53 pchimento Assigned To => pchimento
2012-06-21 06:53 pchimento Status new => assigned
2012-06-21 06:54 pchimento Project Core Inform => Gnome Inform application
2012-06-21 06:57 pchimento Note Added: 0001697
2012-06-21 09:17 NYKevin Note Added: 0001699
2013-04-20 14:41 pchimento Note Added: 0002036
2013-04-20 14:42 pchimento Status assigned => feedback
2013-05-21 12:00 NYKevin Note Added: 0002060
2013-05-21 12:00 NYKevin Status feedback => assigned
2013-05-21 13:53 pchimento Note Added: 0002061
2013-06-14 15:42 EmacsUser Note Added: 0002095
2013-06-15 08:14 pchimento Note Added: 0002096
2013-06-15 11:33 EmacsUser Note Added: 0002097
2013-06-15 11:38 pchimento Note Added: 0002098
2013-06-15 13:23 EmacsUser Note Added: 0002099
2013-06-15 15:35 EmacsUser Note Edited: 0002099 View Revisions
2014-03-24 22:27 pchimento Note Added: 0002587
2014-03-27 14:22 EmacsUser Note Added: 0002596
2014-03-27 14:29 pchimento Note Added: 0002597
2014-03-27 14:34 EmacsUser Note Added: 0002598
2017-08-16 19:49 neroden Note Added: 0004714
2017-08-16 20:15 neroden Issue Monitored: neroden
2017-08-16 22:16 neroden Note Edited: 0004714 View Revisions
2017-08-16 22:48 neroden Note Edited: 0004714 View Revisions
2017-08-16 23:30 neroden Note Edited: 0004714 View Revisions

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker