Memory leak in IDE interpreter?

Authoring Inform 7
1

I’ve been using an extension I created for automated testing. It works by writing a queue of tests to run into a file, then restarting the game using this phrase:

To restart immediately: 
	(- @restart; -).

Each test is deleted from the queue when it is run, so the next test will run after restarting.

If I fill the queue with multiple instances of the same test, it runs noticeably slower each time. If I recompile while a test is running, it continues advancing through the queue, but it’s fast again.

My guess is that there’s a memory leak in the interpreter that the IDE uses. But I have no idea how to isolate the problem. Can anyone help? Thanks!

2

Mac/Win/Linux?

3

Mac, with the same setup as in this thread:

https://intfiction.org/t/glulxe-fatal-error-memory-access-out-of-range-2519010c/7441/1

4

I know of a couple of memory leaks in the Mac IDE interpreter:

inform7.com/mantis/view.php?id=536
inform7.com/mantis/view.php?id=992

Or it could be something related to the displayed text, which I’ve never tried to measure.

5

I looked in Text Capture and found this:

	text_capture_new_stream = glk_stream_open_memory_uni(captured_text + WORDSIZE, CAPTURE_BUFFER_LEN, 1, 0);

That happens every time we start capture, and when we end capture, it does this:

@glk $0044 2 0; ! stream_close

Could that be subject to bug #992?

6

It is likely.

The standard library also calls glk_stream_open_memory_uni in a few places, so it probably happens even without Text Capture.

7

I hope I’m not the only one curious, and I hope this doesn’t derail a thread…

But

  1. is this available on windows too?
  2. I tried the following code, and it just restarted without executing going south…is there any way to (quickly) integrate restarting immediately into a regular testing script, while you’re polishing your extension?
"simple-test" by Andrew Schultz

room 1 is a room.

To restart immediately: 
	(- @restart; -).

test rs with "n/rs/s"

chapter rsing

rsing is an action out of world.

understand the command "rs" as something new.

understand "rs" as rsing.

carry out rsing:
	restart immediately;
8

Try this, aschultz:

[code]Include Text Capture by Eric Eve.
Use maximum capture buffer length of at least 16384.

room 1 is a room.

To restart immediately:
(- @restart; -).

chapter rsing

rsing is an action out of world.

understand the command “rs” as something new.

understand “rs” as rsing.

carry out rsing:
restart immediately;

Before reading a command:
repeat with i running from 1 to 10000:
start capturing text;
stop capturing text.[/code]
The first time I enter “rs,” it takes about 5 seconds to get to a prompt. The second time, about 10 seconds - and 5 seconds more each time.

9

This ran quickly for me. I tried about 15 times and saw no performance degradation.

10

Was it slow enough the first time that you could time it? If not, you could increase the number of repeats until you can.

11

I did an up-arrow, then return, to type RS again. Even after 100 times, things popped up quickly on Windows.

Let me know if there are other tests that can be run.

12

Sorry, I meant the number of repeats in the loop, not the number of times you ran the test manually. Try changing the number from 10000 to 100000, for example. Three attempts should be enough if you can time the first one on a stopwatch.

13

Oops on my part–I wasn’t testing the right thing. I was testing under the z-machine, but when I changed to glulx (as indicated by your glk_ code,) things were less instantaneous.

But I did not see an increase in time taken. It was pretty consistently around 5 seconds for the 10 iterations I tried.

14

Ok, sounds like it’s definitely a problem with the interpreter for the Mac IDE then.