About Patches   Compiler   Library   DM4 Errata

Issue C63023     [previous patch] Various memory problems Submitted by: Mark Tilford     Appeared in: Compiler 6.30 or before     Fixed in: - Problem Using Inform 6.30 on Linux, I'm working on a program that converts ADRIFT files to Inform source code. Due to the way it works, it will usually produce one object with a very large number of properties, and sometimes produces extremely long strings. When I attempt to compile a program where one object has too many properties, the compiler segfaults. I looked to see which property I should increase, but the ones that looked appropriate were all Glulx only. Please handle better (Give an error message like "Too many properties in one object, increase $....") Where there's too much string for one pair of quotes, tell what variable to increase if it's not a bug. inform -u file.inf segfaults, while inform file.inf -u works. Considering that memory has gotten to be a rather cheap resource, perhaps Inform should just get rid of the idea of making the programmer manually choose the compiler allocations, have Inform reallocate them if it needs more space. Solution (by the maintenance team) None yet available. Items 1, 2 and 3 should be fixable. Item 4 would require a major rewrite of the compiler, so is unlikely to happen. Here's one possible approach: that we have a "scale factor" as a simple command-line option, which simply multiplies up all of the memory settings across the board. Then running the compiler at -X8, or some such, would be easy and would effectively remove all hard memory limits except those imposed by the Z-machine architecture and, probably, a few odd bits in the I6 source code. Above all, it would save that whole tiresome business where you raise one memory limit only to find that you haven't raised it enough, and anyway another limit is also in need of raising, and... so on. On top of that, if memory limit errors were reported with a unique return code or easily greppable string, a front end could just repeat the compilation at a higher scale factor over and over until it either succeeds or fails with a non-limit-related error. Wasteful, but easy to implement.

Last updated 2 May 2008. The librarian in charge of this page is Roger Firth. Please email any comments, suggestions or corrections to roger@firthworks.com.