Trinitycore: Crash worldserver: error reading variable

[TheWinchesters]

Description:
Not sure if this case belongs here or it is just a problem related to my setup.
Maybe someone can confirm about it.

Crashlog:
https://gist.github.com/TheWinchesters/8b9bcc4d8d5e30665e73de5221bad358

Branch: 3.3.5
TC Rev.: 7baf5b2
OS: Windows 8.1 - Debian 9

[ghost]

How much cores have been Crashed!

[jackpoz]

could you try building without jemalloc ? do you have any custom change at all ?

[WildCoffee]

Have you tried to run a memory test? You can try memtester, that should catch anything obvious. The number of segfaults you're getting without a discernible pattern point to potentially bad RAM.

Otherwise, can you post the results of the '.server debug' command?

[illfated]

Like WildCoffee said above, this looks a more like the server OS has got issues handling the TC server calls.
Not sure if this is OS or hardware bottlenecks, but it is more likely to be caused by something outside of the TC source.

[TheWinchesters]

Thanks for all the answers.
@jackpoz

• Yes, I can try without jemalloc. Is -DNOJEM = 1 the right way to do it?
• No, I have another compilation with custom changes for learning.

@WildCoffee @illfated
If you are talking about the last crashes I reported, I have thought something similiar, especially with this last crash. I was waiting for someone else to confirm any of them.
Since Azjol 'Nerub and Pinnacle of Utgarde are deactivated in my server, I was not having crashes.
I have had days without problems.
The last 3 crashes I had, are the ones that I have reported, which have not been repeated.
I am using this OVH dedicated server:
Intel i7-4790K (4c/8th) - 16GB DDR3 1333MHz - 120 GB SSD
SO Debian 9.4 Stretch (stable) (64bits)
Could I really think about a ram/hardware problem?

.server debug
TrinityCore rev. 7baf5b245255+ 2018-09-25 01:11:00 +0200 (3.3.5 branch) (Unix, Debug, Static)
Using SSL versión: OpenSSl 1.0.2l 25 May 2017 (library: OpenSSL 1.0.2l 25 May 2017)
Using Boost version: 1.62.0
Using MySQL version: 10.1.26-MariaDB
Using CMake version: 3.7.2
Compiled on: Linux 4.9.103-xxxx-std-ipv6-64
Automatic database updates are enabled for the following databases; Auth, Characters, World
Worldserver listening connections on port 8085
Realmlist (Realm Id: 1) configured in port 8085
VMAPs status: Enabled. LineOfSight: 1, getHeight: 1, indoorCheck: 1
MMAPs status: Enabled
maps directory located in /home/server/data/maps. Total size 252191207 bytes
vmaps directory located in /home/server/data/vmaps. Total size 588247501 bytes
mmaps directory located in /home/server/data/mmaps. Total size 2152621724 bytes
Using esES DBC locale as default. All available DBS locales: esES
Using World DB: TDB 335.64

If all your ideas point to an operating system problem, maybe should I close this? Or we can wait some days to see if someone else confirm this. If nobody does, I could close it.

Thanks again for all your help

edit: I have run memtester 1024 5 and everything is ok.
Also, I am doing a cleanup.

[illfated]

Fair enough. A dedicated server with those specs should (in theory) eliminate hardware bottlenecks.
I am not fluent enough in crash log reading to see exactly what causes that crash.
I leave it up to more experienced coders to give you further advice.

[WildCoffee]

If I read the crashlog correctly, the segfault is actually well inside the standard library. It's 6 calls deep into the standard library before if can't read the memory address. I'm fairly confident this isn't a TrinityCore problem, but there's something wrong with the OS or hardware. Considering memtester came back clean, I'd run memtest86 just to be sure. You only tested at most 5GB of your 16GB (1024MB, 5 times).

Edit: To expand at 7: in Map.h, line 517, the iterator, _corpsesByCell and the cellId exists (145670). From there, it enters the standard library, where the crash actually happens when it can't complete the equal_to call. It looks to me that TrinityCore is passing valid data into the standard library. I'm not the greatest at reading crashlogs, but I think that's what happened.

[TheWinchesters]

Thanks again for the answers, advices and help.
I am sorry if this problem is not related to TC, I would like to help with this project but I am someone who needs to learn a lot and the best I can do now is reporting issues.

[jackpoz]

Yes, I can try without jemalloc. Is -DNOJEM = 1 the right way to do it?

I think so, I use

-DNOJEM=TRUE

which should be the same

[TheWinchesters]

I have tried cmake ../ -DCMAKE_INSTALL_PREFIX=/home/server/server -DMAKE_BUILD_TYPE=Debug -DNOJEM=TRUE and this is the error I get:

By the way, I had another crash some minutes ago. It is about scripts/Northrend/Ulduar/Ulduar/boss_xt002.cpp:754
caster->GetAI()->SetData(DATA_GRAVITY_BOMB_CASUALTY, 1);
Should I post it here in case that it is another crash related to this or Do I create an new issue?

[Killyana]

Into a new issue.

[jackpoz]

try clearing the cmake cache or deleting the build folder and rerunning cmake

[TheWinchesters]

Thanks jackpoz.
OVH provided me some tools to make some hardware/memory tests so, when I finish them I will build without jemalloc

[TheWinchesters]

Update: After some tests, some cleanup, some maintenance tasks in the dedicated server, recompiling... everything seems to work fine.

Nobody else had this problem so we could catalog this error as a "punctual problem not directly related to TrinityCore"
Could we close this topic?

I almost forgot to thank all of you for your answers! Thank you

[illfated]

I agree. There has not been any other issues like this (at least not reported), so I recommend closing this issue as a standalone, localized problem not related to the TC source.

[fan3750060]

确实是这样的,cmake的时候设置-DNOJEM=TRUE可以避免这个问题! 感觉正式一波三折啊

[illfated]

Google Translate of the comment above (https://github.com/TrinityCore/TrinityCore/issues/22543#issuecomment-480139648:)

This is indeed the case, when setting cmake -DNOJEM=TRUE can avoid this problem! Feeling officially twists and turns

@fan3750060 : Please note that this is primarily an English-speaking issue tracker and that this issue ticket appears to be resolved.