Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001110Core InformRelationspublic2013-04-20 09:452014-05-07 07:34
Reporterzarf 
Assigned Tograham 
PrioritynormalSeveritycriticalReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSMac OS XOS Version10.8
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0001110: Compiler crash in complex descriptions
DescriptionSegfault, same location as bug 484 and bug 543.
Minimal Source Text To Reproduce
There is a room.

Every turn:
	showme whether or not a random thing unlocks a door.
Additional Information0 ni 0x00089fa0 Kinds__interpret_test_equality + 128
1 ni 0x000dae12 Calculus__Relations__Equality__compile + 274
2 ni 0x000db3c8 Semantics__BPs__get_i6_schema + 584
3 ni 0x000dca87 i6_schema_of_atom + 455
4 ni 0x000dce2c Calculus__Atoms__compile + 140
5 ni 0x000dd60c Calculus__Propositions__compile_all_deferred + 1260
6 ni 0x0012bd06 Config__Template__interpret + 10326
7 ni 0x0012a966 Config__Template__interpret + 5302
8 ni 0x001314bc main + 636
9 ni 0x00002019 _start + 208
10 ni 0x00001f48 start + 40
TagsNo tags attached.
Effect(critical) Compiler crashes
Attached Files

- Relationships
related to 0000543closedgraham A rule that references a just-called name in a condition describing repetitions causes compiler to fail 

-  Notes
(0002033)
zarf (developer)
2013-04-20 09:52

Happens even if you define a door in the game, by the way.
(0002042)
zarf (developer)
2013-04-20 18:33

Probably beating an already-resolved bug to death here, but:

Foo relates a thing to a door.
The verb to bar (it bars, they bar, it barred, it is barred, it is barring) implies the foo relation.
When play begins:
showme whether or not a random thing bars a door.

...that compiles. If you change the first line to "Foo relates a thing to various doors." then the crash appears. "Foo relates various things to various doors." is again okay.
(0002075)
graham (administrator)
2013-06-01 15:40

Fixed. A nitwit coding error (to my relief, because this meant it wasn't something fundamental that was misconceived); state failing to be saved when deferred loops are compiled, so that if one deferred loop requires another (whether X unlocks D, and a random X, respectively) then the state would sometimes point to the wrong one. So this bug might in principle strike in quite a lot of situations, though in practice it doesn't, because the state in question is usually valid in both cases so that it doesn't matter if we have the wrong one.

- Issue History
Date Modified Username Field Change
2013-04-20 09:45 zarf New Issue
2013-04-20 09:46 zarf Relationship added related to 0000543
2013-04-20 09:52 zarf Note Added: 0002033
2013-04-20 18:33 zarf Note Added: 0002042
2013-04-26 18:57 EmacsUser Status new => confirmed
2013-06-01 15:40 graham Note Added: 0002075
2013-06-01 15:40 graham Status confirmed => resolved
2013-06-01 15:40 graham Resolution open => fixed
2013-06-01 15:40 graham Assigned To => graham
2014-05-07 07:34 jmcgrew Fixed in Version => 6L02
2014-05-07 07:34 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker