Foereaper

Not yet known, haven't had the time to get around to debug it

This is a known spell aura crash, it is not related to the above node issue :) If you're no longer receiving the node crash issues then I believe we've found the culprit! I am promoting the above crash to its own issue on the tracker.

Please test this: git clone [url]https://github.com/mangoszero/server.git[/url] -b Rel20LinuxCrash --recursive This has the new pool system disabled at latest rev

That is the new ore code added on the 13th of September. I will be removing this commit on a test branch and post a link whenever to test with the latest source without the ore system.

[url]https://www.getmangos.eu/issue.php?issueid=177[/url]

If you manage to keep crashing it around Orgrimmar, that would be great :P I have yet to be able to reproduce the crash with the version mentioned above, but not necessarily sure if it's stable just yet. Also, if you have time, please compile with the below: [COLOR=#3E3E3E]git clone [/COLOR][URL]https://github.com/mangoszero/server.git[/URL][COLOR=#3E3E3E] -b Rel20[/COLOR] [COLOR=#3E3E3E]git checkout [/COLOR]5b5d667 [COLOR=#3E3E3E]git submodule init[/COLOR] [COLOR=#3E3E3E]git submodule update This is what I have been testing for the past couple hours, no crashes so far. If you have no crashes with this, then [/COLOR]5b5d667 is a stable revision and helps narrow down what's causing this.

Please try this and let me know how it works out: git clone [URL]https://github.com/mangoszero/server.git[/URL] -b Rel20 git checkout b79a091 git submodule init git submodule update I have tested this for a couple hours so far and it seems to be stable. This includes both the changes to the event system, AND the ore system. If this is stable, then I will seriously have to reconsider what is wrong.. [COLOR=#ff0000][SIZE=3]IGNORE THE ABOVE PART OF THIS POST[/COLOR][/SIZE] It would seem that the above listed commit, b79a091, does NOT contain the new Ore spawn system. This is due to Git being a... Git. b79a091 is STABLE. Will now continue testing on 5b5d667.

Crash just happened! Literally running back and forth between Feralas and the salt flats. Will compile some older revisions and pinpoint where the crash started happening.

I have spent the better half of the evening trying to reproduce this crash. With a Warrior character I have not yet been able to do so. I do have a couple of questions though: - Are either of your characters a character that has any pets? - Are you doing any gathering related professions like mining, herbalism etc?

This has already been reported in a previous ticket, some interesting discussion followed there as well.

The fix that worked for TC was pushed here: [URL]https://github.com/mangoszero/server/commit/426c697a73839b89a117b8f1fc61eee696b6bc7c[/URL] Something else is obviously playing up, though at this point I have no idea what. Like Trinity did, we should recreate the crash in Valgrind for some proper information. For reference sake I would still like for you to try this with both SD2 and Eluna disabled. The more we can rule out the better.

It will, you can disable one, the other, or both if you choose to do so. Least it does on Windows, haven't tested Linux build :) Anyway, some interesting information about the crash. See: [URL]https://github.com/TrinityCore/TrinityCore/issues/5218[/URL] The fix for this was pushed already not too long ago, however it is most likely something along the same lines as what Trinity faced. Also, note that this is a *NIX only issue.

Actually, for testing purposes. Would you mind disabling both Eluna and SD2 and see if any crashes occur?

The last stable version as far as my testing has gone is up until this commit: [url]https://github.com/mangoszero/server/commit/1cd1b9614dec8a519af47bd30a65064d46ad1d2d[/url] I have not yet had the time to venture past that commit, though I suspect it is either the timed event handler rewrite or the new ore system. I somewhat lean towards the latter as the stack trace contains information related to game object models.

[quote=Xenithar]Is it possible to set "CONF_DIR" to "/etc"? If so I can begin making the Debian packages again.[/quote] Yes, however I will have to look into the technical aspects of doing this, as it may cause some issues with relative pathing. Will get to it once I have some spare time.

Fix has been pushed, please test and report back [url]https://github.com/mangoszero/server/commit/9ee406aee5d2997901fa6699b35404fcc05f10aa[/url]

Testing now, will push fix shortly

I am testing a compile with external ACE now.

Say your install prefix is /home/usr/server. By default, the config dir would then be /home/usr/server/etc. If you would like the config dir to be /home/usr/etc, you would then use -DCONF_DIR=../etc/

As of this commit: [URL]https://github.com/mangoszero/server/commit/7e30aa81d033ea89b07cfd307b3310c943488a54[/URL] Linux: - Binary files are now installed at install_prefix/bin - Config files are now by default installed to install_prefix/etc Windows: - Binary files are now installed at install_prefix - Config files are now by default installed to install_prefix CONF_DIR option is relative to install_prefix on both Windows and Linux. On linux this option defaults to: -DCONF_DIR=etc/ Notes: lua_scripts directory and log files location are relative to the binary directory, this means; Linux: install_prefix/bin Windows: install_prefix This can be changed in mangosd.conf, ie. LogsDir = "../logs/" The above would set the logs directory to: install_prefix/logs

I have attempted to recreate this issue for roughly a week so far, unfortunately after 8 hours of gameplay I have not been able to find a good way to reproduce.. If possible, could you note exactly where everyone online are when this happens, as well as what people are doing specifically? Also, if possible, how long the server has been running.

Because the old one is horribly broken and is just a patch job for this to work as is. Also, this is an attempt at fixing the cmake build to be cross platform. Not a change. All of the above is simply install step settings.

Like I said, it is a work in progress. Fixing up the build system is not a one-step task. There is no need to get heated what so ever, simply state what is wrong, how it should be, and we'll get to it. If it is more urgent than that, you could always look at the install file and do the necessary changes for this to work like it should on Linux. For reference sake, the internal ace library has been completely switched out.

This is due to the install step of the new build system, it is not yet complete :)

Good to hear :) The install location was made to be structurally similar to Windows, thus the binaries not being added to the bin folder. Will discuss this with LFX and Rochet as they know the install system better than I do. Will also take a look at using external Ace once we're done porting the system to One. Edit: Saw your update, it is not broken per se. For cmake to work properly on windows with a configurable conf dir, as that was wanted by a few, a new cmake option was added where you can specifically configure the path to the conf dir. -DCONF_DIR