Memory allocation error (z-code) vs blank story tab (Glulx)

Fascinating! I never would have thought this was the cause from the original error message.

Having built a test project with 70 pebbles to replicate the error, I can confirm that this fix appears to work :smiley:

EDIT: Do you want to log it?

2 Likes

Concur with Bates about logging this as I10 bug: I10 having its “hidden punyinform mode” (that is, compiling with OMIT_UNUSED_ROUTINES, whose incidentally seems has helped isolate the bug) squashing said bug IS important, albeit IMVHO.

Best regards from Italy,
dott. Piergiorgio.

1 Like

I don’t have an account for the new system, so please do submit a report on behalf of the MSC if so inclined.

Note that there is a line in BlkDebugAddress() that uses I7SFRAME in some arithmetic:

! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! BlockValues.i6t: Printing Memory Addresses
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====

[ BlkDebugAddress addr flag d;
	if (flag) { print "###"; return; }

	d = addr - blockv_stack;
	if ((d >= 0) && (d <= WORDSIZE*BLOCKV_STACK_SIZE)) {
		print "s+", (BlkPrintHexadecimal) d;
		d = addr - I7SFRAME;							! <--- HERE
		print "=f"; if (d >= 0) print "+"; print d;
		return;
	}
	
	d = addr - Flex_Heap;
	if ((d >= 0) && (d < MEMORY_HEAP_SIZE + 16)) {
		print "h+", (BlkPrintHexadecimal) d;
		return;
	}

	print (BlkPrintHexadecimal) addr;
];

I think it will still work correctly even if the block value stack’s array partly or fully crosses the maximum positive integer boundary, but it’s worth a double-check.

The additional consumption per object is pretty significant. Did you happen to spot any cause(s)?

No, it was a purely empirical observation of how blockv_stack varied after the addition/removal of an object.

Even more striking is how the baseline memory usage below blockv_stack for an empty project is ~6700 bytes in 9.3 but ~18500 bytes in 10.1

Zed is doing so.

I wanted to give you some information, in case it was helpful.

McAfee is showing that both of the glulx interpreters contain some kind of malware called “Artemis!CBF4903FCEFD”.

They do provide an option to exempt specific files, but that just keeps it from quarantining them; it still won’t allow them to execute. The only way I can run them is if I completely disable virus scanning, which is not a great solution.

My concern is not so much that I have to disable my virus scanner when I’m testing, but that other people who download my game are going to run into the same problem, if they have McAfee (although a Google search only shows my post here, so if anyone has had the same problem, they apparently haven’t posted about it).

By the way, thanks again to everyone who helped with my object limit. It fixed the problem for a while, but I did eventually hit the z-code memory limit and had to switch to glulx anyway.

Most people wanting to play your game will either have their own interpreter set up to their liking already, or will play it online with Parchment (which runs in a web browser and thus bypasses McAfee’s paranoia).

2 Likes

Searching around about this, it seems that “Artemis” is a generic term McAfee uses to indicate “suspicious” files, rather than those containing something specific, for example: https://www.mcafee.com/support/?locale=en-US&articleId=TS100414&page=shell&shell=article-view

As ever with this sort of thing, it’s impossible to know exactly what it is detecting, or what one could do about false positives. There are certainly signs that you are not alone in needing some way to explicitly whitelist files, e.g. McAfee Support Community - How to "White List" False Positives Manually? - McAfee Support Community

As someone who has worked for an AV vendor in the past, I stick with my view that the standards of the industry are not high, and that McAfee has a poor reputation even by these low standards. But that probably isn’t much help to you.

3 Likes

For now, I’m just disabling McAfee when I’m testing and playing IF games, and then turning it back on when I’m done.

When my subscription to McAfee runs out, I will definitely be switching to something else.

McAfee is insane.

I reported the false positives, not really expecting them to do anything. To my surprise, after the next update, all of the Glulx interpreters worked fine with McAfee running, as long as I added them to the Excluded Files list.

But after the next update, Inform now fails after compiling and McAfee reports that it “stopped something dangerous”. I tried adding Inform, all of the compilers, and all of the interpreters to the Excluded Files list, but it didn’t help.

I can run games using the standalone Glulx interpreters fine now, but I have to turn off McAfee to run them from inside Inform.

As soon as my subscription expires, I’m dropping McAfee like a hot rock and getting something else. This is ridiculous.

1 Like

I can suggest a good “antivirus”: an free, open-source OS, based on really mature (50+ years of development…) and proven concepts (Unix), that is, Linux ? I use it since 1994, and I never have virus issues in the last twenty-nine years…

Best regards from Italy,
dott. Piergiorgio.