Segfault [Linux] Scriptdev2

[FONT=Verdana][QUOTE=Karel Tucek;72876]!@#$%^&*(... I did not notice the line saying "Scripting library not found or not accessible." at all. [/QUOTE][/FONT][QUOTE=Karel Tucek;72876]

[FONT=Verdana]Well I have no idea why cmake skipped it, but now I got the script library compiled and I am getting the segfault as well.[/FONT][/QUOTE]

Importing reply.

Make sure he can get to this ticket. Have him try the automation script I wrote. I know it isn't released yet but if it solves his issue, it may indicate whatever guide he followed was outdated.

[url=http://dhta.oesm.org/getmangos.sh]MaNGOS Automatic Installation Script For Linux[/url]

Just grab and run that, and it will clone, configure, build, and install the server. It will also setup your databases and update them if needed.

*EDIT*

It looks like he is using Debian Squeeze. He has some old libraries there. Wheezy is up to ACE 6.0.3, which is my main clue. That or an old version of Ubuntu.

Tried your script:
1) note that your line endings do some mess under linux (shabang is not interpretted correctly and escape sequence \ naturally causes an error, as the escape sequence has entirely different meaning to \)
2) It does fail to update the database. It just installed a clear one and let it there without any updates (or technically taket it may possibly have let it on a wrong revision, but my guess is that it did not install any updates at all).
3) As it did not update the database, I tried that build with my installed mangos-zero database. I get exactly the same result as was reported earlier. (which may probably be caused by incorrect scriptdev db version? After all, the guide in wiki I used to install it was most likely deprecated...)
4) The script does not let user go to the database install menu without performing a build. Build which is performed seems to clean first - would not be a make sufficient? (Like this I must recompile entire mangos in order to get to the database menu for the second time) (I wanted to try explicitly the update option...)

my system is 64bit debian wheezy

Alright, the issue I see is the old OS. Squeeze has been "oldstable" for years. I did not test the script on Squeeze and don't intend to. It works flawlessly for me on Wheezy 64bit, Ubuntu/Kubuntu 64bit, and Fedora. I have yet to test it on Slack or Gentoo. May test on Mint also. I have no plans to support Squeeze at this time.

Also, I believe that MaNGOS needs ACE 6 now. I remember reading something about changing the requirement to 6 a while back, but I do not know if that was ever made official. Maybe somebody else can chime in here. Also note that your C libraries are also older than what is on Wheezy. I would suggest using squeeze-backports and updating your development libraries and ACE to see if that helps.

Now that I think about it, I was forced to upgrade to Wheezy a year or so ago on my MaNGOS system. I had been running Squeeze, but something happened and my only choice was to upgrade. After upgrading all was good. This may also be related.

Just to be clear - that quoted log is aleph's backtrace. As I said I am on debian Wheezy 64bit. My ACE is version 6.0.3.

Btw I personally dont really care for this getting resolved, so please dont take this as an argument why you should do something with it (As I said I think problem is in my database but am not going to dig into it further (at least not now)). I am only trying to provide information that may help resolve some problem that even another person experiences (even if it is only due to outdated documentation).

This is what realmd installed by your script produced on my machine:

[36;1mMaNGOS Zero/ (* * Revision 2518 - *) for Linux_x64 (little-endian) [realm-daemon][0m
[36;1m to stop.
[0m
[36;1mUsing configuration file /home/karel/zero/etc/realmd.conf.[0m
[36;1mLogin Database total connections: 2[0m
[36;1mMySQL client library: 5.5.38[0m
[36;1mMySQL server ver: 5.5.38-0+wheezy1 [0m
[36;1mMySQL client library: 5.5.38[0m
[36;1mMySQL server ver: 5.5.38-0+wheezy1 [0m
[31;1mSQL: SELECT required_20140607_Realm_Resync FROM realmd_db_version LIMIT 1[0m
[31;1mquery ERROR: Table 'autozero_realm.realmd_db_version' doesn't exist[0m
[31;1mSQL: SELECT * FROM realmd_db_version LIMIT 1[0m
[31;1mquery ERROR: Table 'autozero_realm.realmd_db_version' doesn't exist[0m
[31;1mThe table `realmd_db_version` in your [REALMD] database is missing or corrupt.[0m
[31;1mMaNGOS can not find the version info needed to check that the db is up to date.[0m

[31;1mThis revision of mangos requires a database updated to:[0m
[31;1m`20140607_Realm_Resync.sql`[0m

[31;1mReinstall your [REALMD] database with the included sql file in the sql folder.[0m
*** glibc detected *** ./realmd: malloc(): memory corruption: 0x00007f4b272f8ec7 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x76aa6)[0x7f4b26fe8aa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x79b13)[0x7f4b26febb13]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7f4b26fed930]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZnwmRKSt9nothrow_t+0x1d)[0x7f4b27a1510d]
/usr/lib/libACE-6.0.3.so(_ZN17ACE_New_Allocator6mallocEm+0x1c)[0x7f4b28944e3c]
/usr/lib/libACE-6.0.3.so(+0xa72cc)[0x7f4b288ff2cc]
/usr/lib/libACE-6.0.3.so(_ZN22ACE_Configuration_Heap18enumerate_sectionsERK29ACE_Configuration_Section_KeyiR15ACE_String_BaseIcE+0x1fc)[0x7f4b2892632c]
./realmd[0x4569de]
./realmd(_ZN6Config13GetIntDefaultEPKci+0x40)[0x456e88]
./realmd(_ZN3Log24WaitBeforeContinueIfNeedEv+0x20)[0x46ad3e]
./realmd(main+0x5a9)[0x44cd92]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f4b26f90eed]
./realmd[0x4421d9]
======= Memory map: ========
00400000-0048f000 r-xp 00000000 08:01 711448 /home/karel/zero/bin/realmd
0068f000-00691000 rw-p 0008f000 08:01 711448 /home/karel/zero/bin/realmd
00691000-00692000 rw-p 00000000 00:00 0
01328000-0136a000 rw-p 00000000 00:00 0 [heap]
7f4b20000000-7f4b20021000 rw-p 00000000 00:00 0
7f4b20021000-7f4b24000000 ---p 00000000 00:00 0
7f4b25f42000-7f4b25f4d000 r-xp 00000000 08:01 919837 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f4b25f4d000-7f4b2614c000 ---p 0000b000 08:01 919837 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f4b2614c000-7f4b2614d000 r--p 0000a000 08:01 919837 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f4b2614d000-7f4b2614e000 rw-p 0000b000 08:01 919837 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f4b2614e000-7f4b2614f000 ---p 00000000 00:00 0
7f4b2614f000-7f4b2694f000 rw-p 00000000 00:00 0
7f4b2694f000-7f4b26966000 r-xp 00000000 08:01 1068968 /usr/local/lib/libz.so.1.2.8
7f4b26966000-7f4b26b65000 ---p 00017000 08:01 1068968 /usr/local/lib/libz.so.1.2.8
7f4b26b65000-7f4b26b66000 rw-p 00016000 08:01 1068968 /usr/local/lib/libz.so.1.2.8
7f4b26b66000-7f4b26b6d000 r-xp 00000000 08:01 920716 /lib/x86_64-linux-gnu/librt-2.13.so
7f4b26b6d000-7f4b26d6c000 ---p 00007000 08:01 920716 /lib/x86_64-linux-gnu/librt-2.13.so
7f4b26d6c000-7f4b26d6d000 r--p 00006000 08:01 920716 /lib/x86_64-linux-gnu/librt-2.13.so
7f4b26d6d000-7f4b26d6e000 rw-p 00007000 08:01 920716 /lib/x86_64-linux-gnu/librt-2.13.so
7f4b26d6e000-7f4b26d70000 r-xp 00000000 08:01 919314 /lib/x86_64-linux-gnu/libdl-2.13.so
7f4b26d70000-7f4b26f70000 ---p 00002000 08:01 919314 /lib/x86_64-linux-gnu/libdl-2.13.so
7f4b26f70000-7f4b26f71000 r--p 00002000 08:01 919314 /lib/x86_64-linux-gnu/libdl-2.13.so
7f4b26f71000-7f4b26f72000 rw-p 00003000 08:01 919314 /lib/x86_64-linux-gnu/libdl-2.13.so
7f4b26f72000-7f4b270f3000 r-xp 00000000 08:01 919307 /lib/x86_64-linux-gnu/libc-2.13.so
7f4b270f3000-7f4b272f3000 ---p 00181000 08:01 919307 /lib/x86_64-linux-gnu/libc-2.13.so
7f4b272f3000-7f4b272f7000 r--p 00181000 08:01 919307 /lib/x86_64-linux-gnu/libc-2.13.so
7f4b272f7000-7f4b272f8000 rw-p 00185000 08:01 919307 /lib/x86_64-linux-gnu/libc-2.13.so
7f4b272f8000-7f4b272fd000 rw-p 00000000 00:00 0
7f4b272fd000-7f4b27314000 r-xp 00000000 08:01 920713 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f4b27314000-7f4b27513000 ---p 00017000 08:01 920713 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f4b27513000-7f4b27514000 r--p 00016000 08:01 920713 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f4b27514000-7f4b27515000 rw-p 00017000 08:01 920713 /lib/x86_64-linux-gnu/libpthread-2.13.so
7f4b27515000-7f4b27519000 rw-p 00000000 00:00 0
7f4b27519000-7f4b2752e000 r-xp 00000000 08:01 919300 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4b2752e000-7f4b2772e000 ---p 00015000 08:01 919300 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4b2772e000-7f4b2772f000 rw-p 00015000 08:01 919300 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4b2772f000-7f4b277b0000 r-xp 00000000 08:01 919316 /lib/x86_64-linux-gnu/libm-2.13.so
7f4b277b0000-7f4b279af000 ---p 00081000 08:01 919316 /lib/x86_64-linux-gnu/libm-2.13.so
7f4b279af000-7f4b279b0000 r--p 00080000 08:01 919316 /lib/x86_64-linux-gnu/libm-2.13.so
7f4b279b0000-7f4b279b1000 rw-p 00081000 08:01 919316 /lib/x86_64-linux-gnu/libm-2.13.so
7f4b279b1000-7f4b27a99000 r-xp 00000000 08:01 1054664 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f4b27a99000-7f4b27c99000 ---p 000e8000 08:01 1054664 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f4b27c99000-7f4b27ca1000 r--p 000e8000 08:01 1054664 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f4b27ca1000-7f4b27ca3000 rw-p 000f0000 08:01 1054664 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7f4b27ca3000-7f4b27cb8000 rw-p 00000000 00:00 0
7f4b27cb8000-7f4b27e82000 r-xp 00000000 08:01 1087353 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4b27e82000-7f4b28082000 ---p 001ca000 08:01 1087353 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4b28082000-7f4b2809d000 r--p 001ca000 08:01 1087353 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4b2809d000-7f4b280ac000 rw-p 001e5000 08:01 1087353 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4b280ac000-7f4b280b0000 rw-p 00000000 00:00 0
7f4b280b0000-7f4b28106000 r-xp 00000000 08:01 1087354 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4b28106000-7f4b28306000 ---p 00056000 08:01 1087354 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4b28306000-7f4b28309000 r--p 00056000 08:01 1087354 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4b28309000-7f4b28310000 rw-p 00059000 08:01 1087354 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
7f4b28310000-7f4b285cf000 r-xp 00000000 08:01 1058410 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f4b285cf000-7f4b287cf000 ---p 002bf000 08:01 1058410 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f4b287cf000-7f4b287d5000 r--p 002bf000 08:01 1058410 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f4b287d5000-7f4b28853000 rw-p 002c5000 08:01 1058410 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
7f4b28853000-7f4b28858000 rw-p 00000000 00:00 0
7f4b28858000-7f4b289cb000 r-xp 00000000 08:01 1070878 /usr/lib/libACE-6.0.3.so
7f4b289cb000-7f4b28bca000 ---p 00173000 08:01 1070878 /usr/lib/libACE-6.0.3.so
7f4b28bca000-7f4b28bdb000 r--p 00172000 08:01 1070878 /usr/lib/libACE-6.0.3.so
7f4b28bdb000-7f4b28bdf000 rw-p 00183000 08:01 1070878 /usr/lib/libACE-6.0.3.so
7f4b28bdf000-7f4b28be1000 rw-p 00000000 00:00 0
7f4b28be1000-7f4b28c01000 r-xp 00000000 08:01 919303 /lib/x86_64-linux-gnu/ld-2.13.so
7f4b28dd6000-7f4b28ddf000 rw-p 00000000 00:00 0
7f4b28dfc000-7f4b28e00000 rw-p 00000000 00:00 0
7f4b28e00000-7f4b28e01000 r--p 0001f000 08:01 919303 /lib/x86_64-linux-gnu/ld-2.13.so
7f4b28e01000-7f4b28e02000 rw-p 00020000 08:01 919303 /lib/x86_64-linux-gnu/ld-2.13.so
7f4b28e02000-7f4b28e03000 rw-p 00000000 00:00 0
7fff3a7a1000-7fff3a7c2000 rw-p 00000000 00:00 0 [stack]
7fff3a7f4000-7fff3a7f5000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
karel@hp625:~/zero/bin$ exit



Anyway thanks for trying to help :-)

It's no problem. I have actually tested the script on Wheezy again after I replied and had no issues. My assistant (we are ahead of schedule today and bored) tried it on a RedHat VM and it worked. These are all current distros though. I really believe the issue being experienced is that you or your friend is on a distro that was out in 2011. Again, I had a major issue with MaNGOS a year or so back and upgrading to Wheezy was my only way to get it going.

It seems like something is VERY wrong with his system though. I am seeing all kinds of symbols and such that should not be there. I would consider a fresh install of Wheezy if it was me personally. Also, if his system is in another language I do not know if that would affect the script.

If you mean the "[36;1" at the beginnings of lines then the explanation is simple: those are just the colour escape sequences which got visible by a typescript redirection. Nothing to worry about :-)

Gotcha', no biggy then. However, has he run a memtest yet? Memory corruption could be a bad chip. If not, was it compiled with standard malloc selected? It may very well be an outdate C library if it was and the memory is in good shape.

*EDIT*

I just added logging to my script. Would you mind running the script again and private messaging me "getmangos.log"? I'd like to see what it says. I also changed a few things to make the script more compatible with older builds of Linux.

Just by the way I have a feeling you have missed one detail - we are 2 completely unrelated guys, just with the same zero-crash problem on loading of scriptdev. Both on debian (aleph squeeze, me wheezy).

I have no idea about *his* memtest but my memory is in a perfect condition (no memtest errors). Besides that I believe that a damaged RAM module would behave randomly (depending on current page mapping or at least on the RAM module used) it would not be reproducible on two different machines or even on one machine in two different times.

Yes, it was compiled with the USE_STD_MALLOC. I tried to recompile without it, but it made no difference.

(I still think that origin of this problem lays in documentation (nothing really wrong with the mangos itself, just unclear/outdated documentation which resulted for me an aleph in skipping of some basic step which was not obvious - we both followed the same guides (probably not exactly the same ones, but we both followed mainly the official wiki improvising on the outdated points)).)

I will send you the log when the script finishes.

*EDIT*
During another round of the script I provided root as the user account (not just admin). This fixed the problem with updating the database.

*EDIT2*
damn, next start caused the crash again.

I did not realize this was the same issue on two different systems. That changes things! Witht hat in mind, I could only think of the problem being a missing dependency. Also, are you running this on a server or in a shell in X (KDE, Gnome, etc)? I run pure servers (no X) and have never tried running in an X environment. That is all I can think of for now, but I will look ino this since it is affecting Wheezy as well.

Also, you must provide your MySQL DB admin credentials when it asks for them. When you (re)install the databases that is required for dropping and creating the databases as well as creating the MaNGOS user and granting it access to the tables.

I do everything using terminal emulators under X, so it should be equivalent to running remotely on a headless server. Only exception is is viewving database, but that should cause no differences.

I have been working with Karel on this issue. I built Zero from scratch and all is good, but it crashes on his system after being built, even with databases and what-not up to snuff. This does not happen on my systems. As you can see in step 8 below, SD2 calls InitScriptLibrary(), which attempts to create an array of a single element. This is where the crash happens.

Now, I am going to check my system and compare databases. All I can figure is that something is wrong and it needs to allocate more than one script element. Might be the DB informing the program of an incorrect number or something else, but I will be digging into it.
[code]
SD2: Loading C++ scripts
[[Thread 0x7ffff1c70700 (LWP 9031) exited]*********] 100%

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5dcc2de in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace
#0 0x00007ffff5dcc2de in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5dce930 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff67f607d in operator new(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff1e195ec in __gnu_cxx::new_allocator

Which file specifically is this in? You could always do a history lookup on github to see when the file was changed last.

It is in "ScriptDevMgr.cpp", line 161. If my memory serves me correctly, the problem was that a class or struct was defined multiple times or something along those lines. However, it was fixed as I ran an R19 server up until last week when I moved to R20.

can someone run a git blame on that file to see the commit that changed it ?

I apologize, but I will be working until 2130 tonight. I will try if I get a second.

*EDIT*

I ran it from my work system. Don't tell the boss.
[code]
@01:~/zero/src/server$ git blame --incremental src/scripts/ScriptDevMgr.cpp
909c1dcabd1aa8a5a91d686a47b69119ee72132a 2 2 1
author Antz
author-mail
author-time 1405675179
author-tz +0100
committer Antz
committer-mail
committer-time 1405675179
committer-tz +0100
summary [Sync] Scripts project sync
previous 60a71cc6559444c73d130d0e35520bddfe3c37a1 src/scripts/ScriptDevMgr.cpp
filename src/scripts/ScriptDevMgr.cpp
909c1dcabd1aa8a5a91d686a47b69119ee72132a 4 4 1
filename src/scripts/ScriptDevMgr.cpp
116b56ac87bd7a63ea4bd8cd7ef08576985948d4 133 133 1
author Antz
author-mail
author-time 1403701079
author-tz +0100
committer Antz
committer-mail
committer-time 1403701079
committer-tz +0100
summary [Sync] Project Sync. Thanks Project Goblin
previous d959e6a7451781e7b30d720596391203da67d36d src/scripts/ScriptDevMgr.cpp
filename src/scripts/ScriptDevMgr.cpp
116b56ac87bd7a63ea4bd8cd7ef08576985948d4 146 146 1
filename src/scripts/ScriptDevMgr.cpp
0c6243ddc5f40b079fb644ea0f495f1776181234 37 37 12
author Antz
author-mail
author-time 1402519295
author-tz +0100
committer Antz
committer-mail
committer-time 1402519295
committer-tz +0100
summary [Scripts] Further merging of Scripts into the core. Scriptdev2.conf settings are now part of mangosd.conf and scriptdev2.conf no longer exists
previous 59db5c5e515443b34cfbf71b812c52f1ef1c0cc2 src/bindings/scripts/ScriptDevMgr.cpp
filename src/bindings/scripts/ScriptDevMgr.cpp
0c6243ddc5f40b079fb644ea0f495f1776181234 94 94 1
filename src/bindings/scripts/ScriptDevMgr.cpp
0c6243ddc5f40b079fb644ea0f495f1776181234 127 127 1
filename src/bindings/scripts/ScriptDevMgr.cpp
0491fbf5b084c4a42dffb5ae0b7bf7f40b8c8f58 234 247 1
author Antz
author-mail
author-time 1401321515
author-tz +0100
committer Antz
committer-mail
committer-time 1401321515
committer-tz +0100
summary [Scripts] Build fixup part 2
previous 6f0eca6da771e68beadd43514b575d1ea4fc162d src/bindings/scripts/ScriptDevMgr.cpp
filename src/bindings/scripts/ScriptDevMgr.cpp
0491fbf5b084c4a42dffb5ae0b7bf7f40b8c8f58 249 262 1
filename src/bindings/scripts/ScriptDevMgr.cpp
0491fbf5b084c4a42dffb5ae0b7bf7f40b8c8f58 253 266 1
filename src/bindings/scripts/ScriptDevMgr.cpp
41c72606bed1c0daf5960231aafb7f617e94ff1c 26 26 1
author Antz
author-mail
author-time 1397817589
author-tz +0100
committer Antz
committer-mail
committer-time 1397817589
committer-tz +0100
summary More Scripting Fixups
previous c1fa7e72927a73af9209366faaf2d39cd1ddc9aa src/bindings/scripts/ScriptDevMgr.cpp
filename src/bindings/scripts/ScriptDevMgr.cpp
41c72606bed1c0daf5960231aafb7f617e94ff1c 35 35 1
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 1 1 1
author Antz
author-mail
author-time 1379961463
author-tz +0200
committer Antz
committer-mail
committer-time 1397772694
committer-tz +0100
summary Script Library Fixup #1
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 3 3 1
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 5 5 21
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 27 27 8
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 36 36 1
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 37 49 45
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 82 95 32
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 115 128 5
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 121 134 12
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 134 147 100
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 235 248 14
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 250 263 3
filename src/bindings/scripts/ScriptDevMgr.cpp
c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 254 267 387
filename src/bindings/scripts/ScriptDevMgr.cpp
[/code]

[URL]https://github.com/mangoszero/server/blame/Rel20/src/scripts/ScriptDevMgr.cpp[/URL] Blame on the said file here :)

[url]https://github.com/mangoszero/server/blame/master/src/scripts/ScriptDevMgr.cpp[/url] Said file on Master

[url]https://github.com/mangoszero/server/commits/Rel20/src/scripts/ScriptDevMgr.cpp[/url]

Did this ever get resolved? I just cloned and installed a fresh Rel19 and I'm running into this issue. Did this get fixed in Rel20, and is it stable enough to use yet? Or if there is a known fix to the source file in Rel20, maybe I could patch it into Rel19?

Here's my world-server.log where it segfaults just after "Loading C++ scripts": [url]http://sprunge.us/Cibf[/url]

This is on a Debian Wheezy 64-bit machine.

Can you please try Rel20 as the entire SD2 has been rewritten as a module, rather than a serparate library (which was causing a lot of issues).

[quote=antz]Can you please try Rel20 as the entire SD2 has been rewritten as a module, rather than a serparate library (which was causing a lot of issues).[/quote]

I'll give it a shot. It's compiling as we speak. Hopefully the needed changes between a Rel19 install and a Rel20 install aren't dramatic. Swap in mangosd/realmd binaries, run sql updates for Rel20, and I'm good to go?

I personally have not had the issue in R20.

If it helps any i just followed this tut to install Zero ([url]https://github.com/mangoswiki/Wiki/wiki/Linuxinstall[/url]) (Slackware64 13.37)
Most went fine except I extracted maps from a windows machine using precompiled executables from a 1.12.1 client because the extractors do not exist in ~/server/contrib/ location of the repository

I also had to run the script to update the real db to REL19 after i found a reference to it in your forums.
server / sql / updates / Rel19 / Realm /

After those 2 hiccups realmd starts fine
mongosd segfaults:


SD2: Loading C++ scripts
[Segmentation fault********************************] 100%

sometimes it does give me the full back trace:


SD2: Loading C++ scripts
[*** glibc detected *** ./mangosd: corrupted double-linked list: 0x0adc4840 ***
======= Backtrace: =========
/lib/libc.so.6(+0x73375)[0xb70e5375]
/lib/libc.so.6(+0x74757)[0xb70e6757]
/lib/libc.so.6(__libc_malloc+0x5a)[0xb70e93da]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb72e0207]
/opt/mangos-server/lib/libmangosscript.so(InitScriptLibrary+0x267)[0xb2d9d7d7]
./mangosd(_ZN9ScriptMgr17LoadScriptLibraryEPKc+0xc89)[0x842c679]
./mangosd(_ZN5World23SetInitialWorldSettingsEv+0x1446)[0x84a27a6]
./mangosd(_ZN6Master3RunEv+0x128)[0x81476d8]
./mangosd(main+0x3e5)[0x8145fa5]
/lib/libc.so.6(__libc_start_main+0xe6)[0xb7088db6]
./mangosd[0x8141681]
======= Memory map: ========
08048000-087e6000 r-xp 00000000 08:02 283387 /opt/mangos-server/bin/mangosd
087e6000-087ea000 rw-p 0079e000 08:02 283387 /opt/mangos-server/bin/mangosd
087ea000-0c4c3000 rw-p 00000000 00:00 0 [heap]
b1100000-b1121000 rw-p 00000000 00:00 0
b1121000-b1200000 ---p 00000000 00:00 0
b12b6000-b12b7000 ---p 00000000 00:00 0
b12b7000-b27f6000 rw-p 00000000 00:00 0
b2c78000-b2dd6000 r-xp 00000000 08:02 283389 /opt/mangos-server/lib/libmangosscript.so
b2dd6000-b2de3000 rw-p 0015d000 08:02 283389 /opt/mangos-server/lib/libmangosscript.so
b2de3000-b35e3000 rw-p 00000000 00:00 0
b3624000-b37c1000 rw-p 00000000 00:00 0
b37fd000-b3834000 rw-p 00000000 00:00 0
b3880000-b580f000 rw-p 00000000 00:00 0
b580f000-b5810000 ---p 00000000 00:00 0
b5810000-b600f000 rw-p 00000000 00:00 0
b600f000-b6010000 ---p 00000000 00:00 0
b6010000-b680f000 rw-p 00000000 00:00 0
b680f000-b6819000 r-xp 00000000 08:02 17398 /lib/libnss_files-2.13.so
b6819000-b681a000 r--p 00009000 08:02 17398 /lib/libnss_files-2.13.so
b681a000-b681b000 rw-p 0000a000 08:02 17398 /lib/libnss_files-2.13.so
b681b000-b681c000 ---p 00000000 00:00 0
b681c000-b701e000 rw-p 00000000 00:00 0
b701e000-b7033000 r-xp 00000000 08:02 17395 /lib/libnsl-2.13.so
b7033000-b7034000 r--p 00014000 08:02 17395 /lib/libnsl-2.13.so
b7034000-b7035000 rw-p 00015000 08:02 17395 /lib/libnsl-2.13.so
b7035000-b7037000 rw-p 00000000 00:00 0
b7037000-b7040000 r-xp 00000000 08:02 17392 /lib/libcrypt-2.13.so
b7040000-b7041000 r--p 00009000 08:02 17392 /lib/libcrypt-2.13.so
b7041000-b7042000 rw-p 0000a000 08:02 17392 /lib/libcrypt-2.13.so
b7042000-b7069000 rw-p 00000000 00:00 0
b7069000-b7070000 r-xp 00000000 08:02 17402 /lib/librt-2.13.so
b7070000-b7071000 r--p 00006000 08:02 17402 /lib/librt-2.13.so
b7071000-b7072000 rw-p 00007000 08:02 17402 /lib/librt-2.13.so
b7072000-b71d3000 r-xp 00000000 08:02 17422 /lib/libc-2.13.so
b71d3000-b71d5000 r--p 00161000 08:02 17422 /lib/libc-2.13.so
b71d5000-b71d6000 rw-p 00163000 08:02 17422 /lib/libc-2.13.so
b71d6000-b71da000 rw-p 00000000 00:00 0
b71da000-b71ef000 r-xp 00000000 08:02 17400 /lib/libpthread-2.13.so
b71ef000-b71f0000 r--p 00014000 08:02 17400 /lib/libpthread-2.13.so
b71f0000-b71f1000 rw-p 00015000 08:02 17400 /lib/libpthread-2.13.so
b71f1000-b71f3000 rw-p 00000000 00:00 0
b71f3000-b720e000 r-xp 00000000 08:02 521335 /usr/lib/libgcc_s.so.1
b720e000-b720f000 rw-p 0001a000 08:02 521335 /usr/lib/libgcc_s.so.1
b720f000-b7233000 r-xp 00000000 08:02 17394 /lib/libm-2.13.so
b7233000-b7234000 r--p 00023000 08:02 17394 /lib/libm-2.13.so
b7234000-b7235000 rw-p 00024000 08:02 17394 /lib/libm-2.13.so
b7235000-b7312000 r-xp 00000000 08:02 523617 /usr/lib/libstdc++.so.6.0.14
b7312000-b7316000 r--p 000dd000 08:02 523617 /usr/lib/libstdc++.so.6.0.14
b7316000-b7317000 rw-p 000e1000 08:02 523617 /usr/lib/libstdc++.so.6.0.14
b7317000-b731e000 rw-p 00000000 00:00 0
b731e000-b7320000 r-xp 00000000 08:02 17423 /lib/libdl-2.13.so
b7320000-b7321000 r--p 00001000 08:02 17423 /lib/libdl-2.13.so
b7321000-b7322000 rw-p 00002000 08:02 17423 /lib/libdl-2.13.so
b7322000-b7335000 r-xp 00000000 08:02 521349 /usr/lib/libz.so.1.2.5
b7335000-b7336000 rw-p 00012000 08:02 521349 /usr/lib/libz.so.1.2.5
b7336000-b7337000 rw-p 00000000 00:00 0
b7337000-b7465000 r-xp 00000000 08:02 17812 /lib/libcrypto.so.0.9.8
b7465000-b747b000 rw-p 0012d000 08:02 17812 /lib/libcrypto.so.0.9.8
b747b000-b747e000 rw-p 00000000 00:00 0
b747e000-b74c5000 r-xp 00000000 08:02 17813 /lib/libssl.so.0.9.8
b74c5000-b74c9000 rw-p 00046000 08:02 17813 /lib/libssl.so.0.9.8
b74c9000-b75e8000 r-xp 00000000 08:02 534339 /usr/lib/mysql/libmysqlclient_r.so.16.0.0
b75e8000-b761d000 rw-p 0011f000 08:02 534339 /usr/lib/mysql/libmysqlclient_r.so.16.0.0
b761d000-b761e000 rw-p 00000000 00:00 0
b7628000-b7632000 rw-p 00000000 00:00 0
b7632000-b77b0000 r-xp 00000000 08:02 282286 /opt/mangos-server/lib/libACE-5.8.3.so
b77b0000-b77bc000 rw-p 0017d000 08:02 282286 /opt/mangos-server/lib/libACE-5.8.3.so
b77bc000-b77be000 rw-p 00000000 00:00 0
b77be000-b77db000 r-xp 00000000 08:02 17446 /lib/ld-2.13.so
b77db000-b77dc000 r--p 0001c000 08:02 17446 /lib/ld-2.13.so
b77dc000-b77dd000 rw-p 0001d000 08:02 17446 /lib/ld-2.13.so
bfcc3000-bfce4000 rw-p 00000000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
Aborted

The REL20 on 746a1e7bd7f090bbf22c753dae755ef3eac6d0e5 seems to work. There are some db errors, but most likely unrelated to this issue... world-server log is here [url]http://84.42.186.246/Up3/world-serverSat_Nov_22_19:52:30_CET_2014.log[/url]