Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000169Core InformRelationspublic2010-07-04 16:222010-10-28 00:31
Assigned Tograham 
Platformx86OSWindowsOS Version7
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000169: Global dynamic relations larger than 32 words are easily corrupted
DescriptionRelations between values defined in the source text, when they grow past a certain size, are at risk of corrupting other data in memory (such as other relations defined below them) or being corrupted by it.
Minimal Source Text To Reproduce
Home is a room.

Foo relates various numbers to various numbers. The verb to foo (it foos, they foo, it is fooing, it 
is fooed) implies the foo relation.

1 foos 2.
2 foos 3.
3 foos 4.
4 foos 5.
5 foos 6.
6 foos 7.

Bar relates various numbers to various numbers.

Test me with "relations".
Additional InformationThe example above displays (on Z-code):

>[1] relations
  0 >=> 0
  16470 >=> 25018
  29923 >=> 3840
  80 >=> -1
  3 >=> 4
  2 >=> 3
  1 >=> 2

The initialization of "bar" has corrupted the contents of "foo".

This appears to be caused by the fix for 0000049. In 6E59, global dynamic relations were used directly from the heap. In 6E72, they're still allocated on the heap, but then copied to statically allocated memory and used from there (presumably so that the static address can be used as a constant). When they outgrow their static allocation, their memory overlaps with other data defined afterward, leading to corruption. Also, the heap memory is never reclaimed.
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
related to 0000049closedgraham Can't statically store relations of values in variables 

-  Notes
graham (administrator)
2010-10-10 07:57

The scheme here is not quite as odd as it looks. We do indeed need the global relation to be at a fixed, I6-constant position in memory, so that it can be used as a constant elsewhere. It therefore wants to be the first block of a possibly multi-block memory allocation which will hold the relation's data during play. However, I7 doesn't know how to initialise relation data (this is all done at run-time in RelationKind.i6t), so it compiles a blank array large enough to hold the opening block and compiles code which will set this block up correctly. This is done by creating a suitable relation and then copying over the block.

The bug was that I7 thought a relation initially used 32 words of data; it actually uses 128. So the space for the initial block of "foo" wasn't large enough, and was overlaid by the initial block of "bar".

The heap-resident block, now representing 128 words of data never to be used, is indeed never reclaimed. This is in order to avoid destroying any objects it points to - indexed texts, for instance. (We could clearly find a way around this if we wanted to, but it's not very much memory.)

- Issue History
Date Modified Username Field Change
2010-07-04 16:22 jmcgrew New Issue
2010-07-04 16:22 jmcgrew Assigned To => jmcgrew
2010-07-04 16:22 jmcgrew Status new => assigned
2010-07-04 17:37 jmcgrew Relationship added related to 0000049
2010-07-04 17:54 jmcgrew Severity mild => serious
2010-07-04 17:54 jmcgrew Status assigned => confirmed
2010-07-04 17:54 jmcgrew Summary Dynamic one-to-one relations don't work in some cases => Global dynamic relations larger than 32 words are easily corrupted
2010-07-04 17:54 jmcgrew Description Updated View Revisions
2010-07-04 17:54 jmcgrew Steps to Reproduce Updated View Revisions
2010-07-04 17:54 jmcgrew Additional Information Updated View Revisions
2010-07-04 17:56 jmcgrew Additional Information Updated View Revisions
2010-07-04 18:45 vimes Issue Monitored: vimes
2010-07-04 19:52 jmcgrew Assigned To jmcgrew =>
2010-10-10 07:57 graham Note Added: 0000683
2010-10-10 07:57 graham Status confirmed => resolved
2010-10-10 07:57 graham Resolution open => fixed
2010-10-10 07:57 graham Assigned To => graham
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:31 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker