Zone crashes in XS__ChooseRandom

[mx4life]

Been building the latest source from github and got it working (mostly), but my zone.exe keeps crashing every time a perl quest script uses quest::ChooseRandom(...). ( embparser_api.cpp (1535): XS__ChooseRandom )

I'm building it with Visual Studio 17 Community edition as 64 bit on 64 bit version of windows 7. Got ActivePerl 5.16.3.1604 x64 installed that it builds against. I tried installing ActivePerl 5.26.3.2603 x64, but that one did not contain a perl526.lib file, but instead had a libperl526.a (unix lib?).

Other perl quest scripts seems to work, it's just ChooseRandom that crashes the zone, so I don't think I have screwed up the build completly.

Zone crash log

https://gist.github.com/Akkadius/3c0...962b5045c3f094

[mx4life]

It looks like it is

int index = zone->random.Int(0, items - 1);

that is returning numbers larger then items -1;

This feels kinda serious since that function is used in many places.

[Uleat]

Does it work sometimes?

You may be sending items = {0, 1} ..

..which would yield:

zone->random.Int(0, 0)

and

zone->random.Int(0, -1)

[Akkadius]

Biggest glaring thing I see is the version of Perl, right now we push 5.12.3 in all of our builds and installers because of the issues that can occur through the Perl API otherwise. We've pretty much been version locked at that x86 lib for the longest time at least as far as Windows is concerned.

I've also noticed we have the wrong version posted on our ground up install which needs to change.

The best frame of reference is here:

https://github.com/EQEmu/Server/wiki...-the-installer

We also officially support x86 for Windows, there is no real need to be using x64 across the board and can cause stability issues and inconsistencies in weird places that can leave you to be troubleshooting for sometime without any clear indication of what is actually going wrong (Seg faults or otherwise)

[mx4life]

So you are saying I should switch back to x86?
I realize there is no reason really to compile eqemu as 64 bit, it was just that I got the impression that it was the supported platform. I've even seen people asking about what the "last" 32 bit version was.
I thought EQEmu had switched over to 64 bit since all the download links for the dependencies where pointing to 64 bit versions. (MySql, Perl, LuaJit)

Perl 5.16.3 x64 is the one that the "Ground up Windows" on the wiki linked to. And getting hold of the older versions seems kinda difficult. I couldn't find them on ActivePerl's site at least.

I changed the function into:

XS(XS__ChooseRandom);
XS(XS__ChooseRandom) {
	dXSARGS;
	if (items < 1)
		Perl_croak(aTHX_ "Usage: quest::ChooseRandom(option1, option2, option3, option4, option5...[no limit])");

	int index = zone->random.Int(0, items - 1);
	if(index >= items) index = items - 1;

	XSprePUSH;
	PUSHs(ST(index));

	XSRETURN(1);
}

(Yes, I do realize that the "if(index >= item)..." will make it generate bad random. It was just to test if that was the reason for the crash)

I changed the code from manipulating the perl stack directly into pushing the return value on to the stack with the perl api first because I thought it had something to do with that first. But it was the check for index >= items that "fixed" the crash.

The perl script I've been testing with is tutorialb/Vahlara.pl so the line that crashes zone.exe is:

quest::summonitem(quest::ChooseRandom(54217,54218,54219,54220,54221,54222,54223,54225,54226,54227,54228));

[mx4life]

Originally Posted by Uleat

Does it work sometimes?

You may be sending items = {0, 1} ..

..which would yield:

zone->random.Int(0, 0)

and

zone->random.Int(0, -1)

How would sending "items = {0, 1}" yield "zone->random.Int(0, -1)"??

The variable "items" is the number of variables sent to ChooseRandom, so how could that be -1? And there is already a check for if it is < 1.

[Akkadius]

The matter on what is officially supported is a disconnected communication happening from a few different sources. Just because we have x64 links out there doesn't mean that is what we vet from a stability perspective. All of our Windows builds that we CI and get pushed out in the installer are x86

Anytime I've seen x64 compilations on Windows there's been all kinds of weird anomalies. On Linux, we use a mix and we at least have largest servers in the community able to vet and QA the code as we are forced to deal with the issues that come up but there really aren't any in today's world after the many many years of work gone into the core

If you want to have a stable experience, follow what the installer instructions set out for versions and you'll be golden.

By all means if you want to spearhead x64 and troubleshoot weird issues just like the one in this thread, be my guest, because it will simply lead to time sinks. x64 definitely compiles and you can run a server on it and things can appear fine, but segmentation faults can send you down an infinite rabbit hole. If you want a stable environment, I would definitely recommend following what's here:

https://github.com/EQEmu/Server/wiki...-the-installer

Later versions of Perl, you don't know how Perl XS is going to behave, what reserved words are now no longer reserved and then produce a stack trace when the function is invoked in a zone. There's been a lot of radical changes further down the Perl line as well and we see no real reason to even consider support for later versions because the C interface has been absolutely terrible hence the drive to have support for languages such as LUA which are far more elegant and mature for said use case

Hopefully that helps a bit

[mx4life]

Thank you very much for your answers. I will be switching to building it as x86 then. I don't really feel I'm qualified to spear head the 64 bit version :P

Found a 32bit version of ActivePerl 5.12.3 on your github, so will use that one.

Isn't Perl a pretty good scripting language? But I guess it is overkill for scripting quests and npc responses.

[mx4life]

Build EqEmu as 32 bit with Perl 5.12.3 and now it works without my "fix" to ChooseRandom.