LuaUI (0.74b3) may cause crashes when hosting

[trepan]

LuaUI in 0.74b3 may cause crashes. The problem is described at:
http://spring.clan-sy.com/mantis/view.php?id=408

It should only affect the host player (the player running the server).

The likelyhood of a problem increases with the number of local
messages that the server generates. Note that not having an
AddConsoleLine() call-in defined in the lua code does not cure the
problem.

As it may be a while before there is another Spring release, I've also
created a patch for 0.74b3 users that compile their own execs. Note
that this patch also includes the new GetConsoleBuffer() call-out.
http://trepan.bzflag.bz/spring/luaui_co ... .74b3.diff

This problem is probably also dependant on the OS being used.

Here's the SVN commit comment:

Code: Select all

* Fixed Mantis bug #0000408 (Logging race condition with lua) by maintaining
  a buffer of raw lines in InfoConsole, with a newLine count. This also has
  the effect of giving LuaUI the new lines that occurred before it was started.

* Added LuaUI GetConsoleBuffer() call-out, to get console lines that occurred
  before LuaUI was started (the maximum buffer size is currently set to 1024)

[LordMatt]

What about creating a binary for those of us who fail at compiling anything?

[trepan]

Beg Tobi, I don't do windows

[ZellSF]

So does this patch break sync with 0.74b3 or not? (I assume it doesn't, but better ask :P)

and applying the patch is done by writing "patch -p0 < patchname" in the directory I have Spring's source?

[AF]

Whats wrong with pushing out a minor fix rather than asking people to compile an svn version. Most software groups (opensource and commercial) would make a minor release 0.74b3b. This is perfectly possible.

Take the 0.74b3 installer, replace spring.exe, rename the b3 bit in the install script, and push it out again. No need for everybody else to be there, no need for betalord to come along with a client, or tobi to say his resync code is fine, or patches to be tested, just fix the bugs and release a new executable. It isnt hard. AI makers, mappers, and modders in spring do it all the time, infact when Fnordia and SJ where in charge they did it too.

[ZellSF]

AF, this *is* a minor fix, for 0.74b3, it doesn't require compiling the svn version, but 0.74b3.

There's nothing stopping anyone from compiling 0.74b3 with this fix and distributing it.

It's not like it happens to everyone either way (must have LuaUI enabled, must be server, still only happens to certain users who does both those...)

[Tobi]

AF, wrong.

You forget basically 90% of what needs to be done for a release, even if it's a minor one (and no it isn't hard, it just takes a reasonable amount of time):

New tag, merging the patch in the tag, make a new compile, test the new compile, modify the installer to allow updating over 0.74b3, configure the server to push out the update, restart the server, modify TASClient to recognize the new server, compile TASClient, create the installer, test the installer, make new debs, upload new debs, test new debs, make new source packages, test new source packages, upload new source packages, make new ebuilds, upload new ebuilds. So Betalord, Yeha and I will be needed at least...

And once that's done another "major" ( ) bug pops up so if we do that development grinds to a halt.

Why don't you just disable LuaUI if you experience this bug, it's not that hard you know...

[AF]

Just a few points. In the mean time does anybody feel like releasing a minw32 builds of spring incorporating these patches? I can only do a MSVC 2003 build atm.

Tasclient doesnt need recompiling, as it doesnt hold the version of spring internally, but rather starts spring.exe when loading in order to determine this. The version of spring is provided to tasclient on login by the server and if they dont match the client auto asks for a download address and if provided by the server is autodownloaded.

The process for lobby spring versions was changed to this in the 0.74b3 release, and as such pushing a patch out across the server does not require any modification of the tasclient binary.

And I'm aware of the stuff with NSIS installers, I made NSIS installers myself for NTai and they're relatively quick when done with the provided tools. And there is both mingw32 for linux and NSIS windowsinstall generator for linux.

Certain comments kloot made in the AI forum about AI interface patches gave me the impression the svn stuff was a lot easier, as does a lot of stuff everybody else keeps saying insisting to me I should know everything in svn possible as its not that hard.

Indeed the whole thing could be done by 1 person and a little cleverness (ebuilds that arent hardcoded to a specific install but instead check and ask the user for example), assuming that 1 person is using a linux environment(I've not heard of people generating deb packages on windows).

And indeed if this fix is the only change made to the source archive at the downloads page or in the tagged revision, and its been made by a dev, and is being spread out in a dev forum thread, then testing should already have been done (by trepan whose hardly likely to have started this thread if he hadn't).

[ZellSF]

Let's see...

1: compile for win32
2: compile for linux
3. make debs
4. make ebuilds
5. make nsis installer
6. make new source release
7. merge patch in tag
8. instruct server to ask people to download the update.

Personally I think that sounds like a lot of work for a single person for an issue that only affects (effects?) a few users. Not that I know any of this, it just sounds like a whole lot of work.

[AF]

strike out "2: compile for linux" as its the linux user who does that via the second two items.

The last one requires 2 values in a server config file be changed.

And if I'm not mistaken why couldnt the following items be accumulated into a script that asks for an svn revision?

3. make debs
4. make ebuilds
6. make new source release

After which another script can compile spring for mingw32 and move it to the correct place then run NSIS, taking a versionname a a parameter:

1: compile for win32
5. make nsis installer

reducing the whole release cycle to:

1. merge patch in tag
2: Run release scriptfile
3. instruct server to ask people to download the update.

To which its even arguable that item 3 can be incorporated.

[ZellSF]

And if I'm not mistaken why couldnt the following items be accumulated into a script that asks for an svn revision?

SVN? This is 0.74b3 with a patch, linked to in the first post.

And if I'm not mistaken why couldnt the following items be accumulated into a script that asks for an svn revision?

Because confusing package managers is so fun! Why not just ask everyone to recompile everything from source in that case? It just wouldn't be a proper release.

You could also reduce the work further by not having an NSIS installer too. Just rar it. Or ask Windows users to compile it too.

(uh, yeah, I might be rather wrong here, but you get the point)

[AF]

Not at all.

Merge the patch into that specific tag.

Run the script, giving the tag when asked

*script does work*

Upload what the script gave you (perhaps this can be done via script too?)

increment sprign version in server config and change downlaod url accordingly (its possible this could be done via script too using web based backend to issue the order but its a trivial action as it is)

[ZellSF]

Yes, but with a script, you wouldn't have a proper release and it'd be the same as zipping the Windows version as opposed to making an nsis installer.

If there's to be a new release, skipping these points will just make Spring far less user friendly for no good reason. Even not counting that, you think there's no work invovled in writing said script?

All for a issue which I haven't even heard of Windows users having yet :/

[AF]

Windows users dont make release installers do they?

And it is indeed possible to genereate the windows installer using NSIS and a command line on linux.

And indeed the end results the same wether you use the script or not, as any NSIS stuff that needs changing will be done by modifying the NSIS scripts not the release script, and those NSIS scripts are a part of the svn anyway.

And yes there is work in making the script, but thats a write once issue. You wont have to do the work everytime you want to use it. I would write it myself if I had a proper linux environment to test it in.

[ZellSF]

Windows users dont make release installers do they?

That wasn't the point at all, but that a script would be the same as a self-extracting archive in Windows. It would not be a proper release.

Unless you're talking about a script to make the debs and the ebuilds, in which case, it's more work than just making the debs and ebuilds, probably :/

And yes there is work in making the script, but thats a write once issue.

Again, why write it even once if it effects as good as no users?

[Tobi]

Umm, seriously, if making such a "one script to rule them all" script was that easy I'd already done it long time ago:

1) I did not yet manage to build a crosscompiling stable gcc release >= 4.0 on linux, hence windows is needed to compile, and reboots/VM starts etc. are pretty complex to put in a script.
2) nsis on linux generates slightly different installers then nsis on windows, iirc it borks on file associations or something.
3) Debs need to be maintained. You can't just change the version and recompile, you need to put a new changelog entry in it, build new .orig.tar.gz etc. (how can you even suggest that should be scripted without knowing how to build them yourself?), then update your pbuilders for the various distributions and compile the new source package in each of those pbuilders...
4) Ebuilds need to be maintained etc. (same as for debs), I've no clue how exactly that works so I can impossibly build a script for it...
5) Stuff needs to be uploaded, which also takes quite some work (filling in all fields at Berlios etc.).
etc.
etc.

(note how some of the steps I mentioned can even be split in 5-6 substeps)

Also, the patch should of course not be merged in the b3 tag because that'd just make one big mess of everything. (ie. original 0.74b3 release would essentially be gone from SVN, source packages would mismatch with tag, etc.).

You can get a live CD with linux, then you can make it...

EDIT: my point is, while it may be easy to quickly push out a new version of a small single language win-only project, it is much more work to push out a new version of a 150ksloc multi language cross platform project like Spring...

[Pxtl]

Whoop, didn't read the thread and made an asinine, redundant comment. How do I delete my own post?

[AF]

You can get a live CD with linux, then you can make it...

x11serv failed to initialise, no screens found

-----------

Unless you're talking about a script to make the debs and the ebuilds, in which case, it's more work than just making the debs and ebuilds, probably :/

wow, I didnt realize you thought I was suggesting the user run a script which autobuilds an NSIS installer and deb packages etc just to install it user side =s.

[ZellSF]

I was thinking you meant a script installer for Linux, not that.

[AF]

ooh, isnt that what the debs/ebuilds are?