nwnx / nwnx2-linux Goto Github PK

Ruby 1.9.x has a small bug that doesn't set up the whole env properly when doing it like we do. This means that some things related to threads/mutexes aren't available.

See: http://www.ruby-forum.com/topic/4408161

Wrote a post on the nwnx.org about what I think is causing this:

I formed a hypothesis about what it's causing the memory leak in nwnx_resman. From what I can tell it only occurs when an external resource is loaded that is not represented in one of the Key tables.

Load some file ->
GetResObject from key table, if none or no entry exists, create new res object ->
SetResObject in the key table, if there's an entry ->
Request/Demand actual file data.

So... if the file isn't in one of the key tables, it's leaking the CRes[...] and file data every Demand. At least that's my theory.

I'm not sure what the best way to go about fixing it would be tho.

With nwnx_spells a half-orc with first level of Wizard class does not see the spell circles besides level 0.

it appears that resman no longer monitors its directories. it used to work so that placing a new file in one of the appropriate subdirectories under the resman directory [e.g., .ncs files in the 'ncs' subdirectory] would cause resman to take note of it and import the resource. this no longer happens. the plugin sets the correct directory source path and RegisterDirectoryHandlers() appears to be called correctly, but both HandleResourceExistsEvent() and HandleDemandResourceEvent() are NEVER called... this was working perfectly in the 2008 version, but now does absolutely nothing.

GetLocalVariableByPosition and GetLocalVariableCount don't work on areas and the module: the offsets are wrong (exalt structs don't account for multiple inheritance in CNWSArea and CNWSModule).

Pickpocket doesn't work with the latest version of nwnx_defenses. Every skill check ends with failure.

Hi,
I'm aware of an Issue #79 but still I don't lose my hope.
Now, when new Raspberry PI 3 is out, I think it may be a good time to consider a cross-compile from x86 application code to ARM that RPI3 has.
Has anyone tried it already? Or maybe someone tried to emulate it? If so, then is it worth it?
It's just... sometimes it does not calculate to host a 24h 10player server on a 60-70W computer.

I'd like to amend a setting to our code guidelines, specifically to our astyle settings:

align-pointer=type

I'm seeing lots of pointer mixup, sometimes left, sometimes right, sometimes in the middle. Granted this will mean we'll see lots of whitespace churn, but I think it's preferrable to have it all in a unified style.

Also, I'd still like to add some whitespace after/before if blocks (at least as a "hard" guideline):

break-blocks

I know that's a bit controversive but I think it makes code more readable and fosters functions that aren't a million lines long.

We could also add a .astylerc config file to the repository, but that idea is neither here nor there.

Maybe this all is something for the new unified codebase at least?

The defenses, spells, and tweaks plugins fail to compile on GCC 4.8 since calling sizeof() on a pointer without dereferencing it now produces a warning.

To fix, change sizeof(value) to sizeof(*value) in the following files:
plugins/defenses/funcs/f_GetDefenseOption.c
plugins/defenses/funcs/f_SetDefenseOption.c
plugins/spells/funcs/f_GetSpellOption.c
plugins/spells/funcs/f_SetSpellOption.c
plugins/tweaks/funcs/f_GetTweakOption.c
plugins/tweaks/funcs/f_SetTweakOption.c

For more info, see https://gcc.gnu.org/gcc-4.8/porting_to.html

Working with some of the database stuff again, building on CentOS 6.4, I found that the SQLite adapter was producing a server memory fault (glibc detected ... free(): invalid pointer) when extracting an object via RCO from the database. The return pointer passed back is to a statically allocated fixed size buffer. It appears that the server attempts to deallocate this with free, producing the fault. Patching the code to return a heap allocated buffer eliminates the problem. Patch submitted.

The nwnx_fixes that is included in this repo is seg faulting on Ubuntu Xenial LTS after a supposed successful compile of nwnx2 and all plugins. The source for nwnx_fixes on virusman's site is a newer version than here. I have tried compiling it, but haven't tracked down all of the errors it threw yet.

Add
set(CMAKE_ASM_FLAGS "-mtune=i386 -m32 -mno-accumulate-outgoing-args -Wall -Wno-unused -Wno-write-strings")
to the CMakeLists.txt

On debian/ubuntu, apt-get Install lib32stdc++-5-dev:amd64, zlib1g-dev:i386, and then optionally the :i386 versions of everything in plugins/*/apt-dep

Any area (re)loaded with nwnx_areas does not have a name string when hovering over party portraits.

Manually setting a name with SetName or the name function in nwnx_areas does not have any visible effect.

NWNXChatGetPCID is not defined in nwnx_chat.nss
http://www.nwnx.org/phpBB2/viewtopic.php?t=2485&sid=ea71deaf2b639d7af9fb977067232f3d

There is a typo on line 90 of NWNXChat.cpp in the chat plugin that can be very confusing when configuring chat. The processNPC flag value is printed for the silent_shout flag value. The patch is essentially:

replace: Log (1, "ignore_silent: %d\n\n", processNPC);
with: Log (1, "ignore_silent: %d\n\n", ignore_silent);

I meet this issue below :
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.8")

And the follow command make sense. Maybe you could update the readme.md.
sudo apt-get install zlib1g-dev:i386

I followed the steps and when I launch "make" I get this error:

Scanning dependencies of target always_rebuild_compiled [ 0%] Built target always_rebuild_compiled Scanning dependencies of target nwnx2 [ 1%] Building CXX object CMakeFiles/nwnx2.dir/nwnx2lib.cpp.o [ 1%] Building CXX object CMakeFiles/nwnx2.dir/NWNXBase.cpp.o [ 1%] Building C object CMakeFiles/nwnx2.dir/modules.c.o [ 1%] Building C object CMakeFiles/nwnx2.dir/lists.c.o [ 1%] Building CXX object CMakeFiles/nwnx2.dir/gline.cpp.o /home/nwn/nwnx2-linux/gline.cpp: In member function ‘int gline::parse(const char*)’: /home/nwn/nwnx2-linux/gline.cpp:40:34: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if ((j = line.find('#')) != line.npos) ^ /home/nwn/nwnx2-linux/gline.cpp:59:56: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if ((pos = line.find_last_of(']')) != line.npos) { ^ /home/nwn/nwnx2-linux/gline.cpp:69:48: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if ((pos = line.find('=')) != line.npos) { ^ [ 2%] Building C object CMakeFiles/nwnx2.dir/lib/nwn_data.c.o [ 2%] Building C object CMakeFiles/nwnx2.dir/lib/nwn_funcs.c.o [ 2%] Building C object CMakeFiles/nwnx2.dir/lib/nwn_hooks.c.o [ 2%] Building C object CMakeFiles/nwnx2.dir/lib/nx_hook.c.o [ 2%] Building C object CMakeFiles/nwnx2.dir/lib/nx_log.c.o [ 3%] Building C object CMakeFiles/nwnx2.dir/lib/nx_safe.c.o [ 3%] Building C object CMakeFiles/nwnx2.dir/lib/nx_signature.c.o /home/nwn/nwnx2-linux/lib/nx_signature.c: In function ‘nx_sig_search_match’: /home/nwn/nwnx2-linux/lib/nx_signature.c:35:40: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (((match >> 8) & 0xFF) && p == ((match >> 8) & 0xFF)) ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:38:41: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (((match >> 16) & 0xFF) && p == ((match >> 16) & 0xFF)) ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:42:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] return (p == (match & 0xFF)); ^ /home/nwn/nwnx2-linux/lib/nx_signature.c: In function ‘nx_sig_search_destroy_nodes’: /home/nwn/nwnx2-linux/lib/nx_signature.c:69:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < count; i++) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c: In function ‘nx_sig_search_add_signature’: /home/nwn/nwnx2-linux/lib/nx_signature.c:128:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (j = 0; j < state->nxss_count; j++) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c: In function ‘nx_sig_search_run’: /home/nwn/nwnx2-linux/lib/nx_signature.c:180:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < cursors; i++) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:184:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (j = 0; j < cur[i]->nxsc_state->nxss_count; j++) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:194:39: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (k = 1; k < cursors; k++) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:199:31: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (k == cursors) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:215:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 1; i < cursors; i++) { ^ /home/nwn/nwnx2-linux/lib/nx_signature.c:223:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < cursors; i++) { ^ [ 3%] Building CXX object CMakeFiles/nwnx2.dir/lib/NwnDefines.cpp.o [ 3%] Building ASM object CMakeFiles/nwnx2.dir/api/nwnsyms.S.o /home/nwn/nwnx2-linux/api/nwnsyms.S: Messages de l'assembleur: /home/nwn/nwnx2-linux/api/nwnsyms.S:1: Erreur: expression absolue erronée ou irréductible /home/nwn/nwnx2-linux/api/nwnsyms.S:1: Erreur: chaîne manquante CMakeFiles/nwnx2.dir/build.make:374 : la recette pour la cible « CMakeFiles/nwnx2.dir/api/nwnsyms.S.o » a échouée make[2]: *** [CMakeFiles/nwnx2.dir/api/nwnsyms.S.o] Erreur 1 CMakeFiles/Makefile2:104 : la recette pour la cible « CMakeFiles/nwnx2.dir/all » a échouée make[1]: *** [CMakeFiles/nwnx2.dir/all] Erreur 2 Makefile:83 : la recette pour la cible « all » a échouée make: *** [all] Erreur 2

It complains about:

-- Could NOT find Ruby (missing:  RUBY_EXECUTABLE RUBY_INCLUDE_DIR RUBY_LIBRARY) (Required is at least version "1.8")
CMake Warning at plugins/ruby/CMakeLists.txt:11 (message):
  Cannot find ruby libraries.

And on x86_64 there is no i686 binaries for Ruby.

Also it can't compile the libraries:

make[2]: *** No rule to make target `/usr/lib/liblua.so', needed by `compiled/nwnx_lua.so'.  Stop.
make[2]: Leaving directory `/home/nwn/nwnx2-linux'
make[1]: *** [plugins/lua/CMakeFiles/lua.dir/all] Error 2
make[1]: Leaving directory `/home/nwn/nwnx2-linux'
make: *** [all] Error 2

Even though I have lua-devel.i686 installed

Solved: Needed lua.i686.

Is it compatible with ARM architecture? Can I compile it for a Raspberry Pi 2?

Thanks,
Claudio

The Dev Crit hook was added in this commit:

d1b8c89

In my local VM that code seems to work fine. However, when I run nwn on our hosted environment (esxi) I always get a segfault in that code. The NWNX modules are loaded in a different order on the hosted environment too, if that matters.

The symptom is that in a module on the hosted environment, if a PC uses a weapon like a longsword, as soon as the PC attacks any NPC/creature, then nwserver segfaults.

Ubuntu 16.04 32bit VM for both hosted VM and local VM

Here is some output from debugging in GDB:

$ gdb --args ./nwserver -publicserver 0 -servername "tester" -port 5142 -dmpassword dmpass -playerpassword playerpass -oneparty 0 -pvp 2 -difficulty 3 -elc 0 -ilr 0 -reloadwhenempty 0 -module "mymodule" -maxclients 14 -servervault 0 -maxlevel 40 -gametype 0 -autosaveinterval 0
(gdb) set exec-wrapper env 'LD_PRELOAD=./nwnx2.so' 'LD_LIBRARY_PATH=lib/:$LD_LIBRARY_PATH'
(gdb) run

Thread 1 "nwserver" received signal SIGSEGV, Segmentation fault.
0x672f4dec in ?? ()
(gdb) backtrace
#0  0x672f4dec in ?? ()
#1  0xb7a0b0f0 in CNWSCreatureStats__GetEpicWeaponDevastatingCritical_hook(CNWSCreatureStats*, CNWSItem*) ()
   from ./nwnx_events.so
#2  0x080ed086 in CNWSCreature::ResolvePostMeleeDamage(CNWSObject *) ()
#3  0x080e9a28 in CNWSCreature::ResolveMeleeAttack(CNWSObject *, int, int) ()
#4  0x080e6fd9 in CNWSCreature::ResolveAttack(unsigned long, int, int) ()
#5  0x080e687d in CNWSCreature::AIActionAttackObject(CNWSObjectActionNode *) ()
#6  0x081c264e in CNWSObject::RunActions(unsigned long, unsigned long, unsigned long long) ()
#7  0x08119285 in CNWSCreature::AIUpdate(void) ()
#8  0x08096161 in CServerAIMaster::UpdateState(void) ()
#9  0x080a0530 in CServerExoAppInternal::MainLoop(void) ()
#10 0xb7f7a4ea in Hook_MainLoopInner(void*) () from ./nwnx2.so
#11 0x0804bbe7 in main ()

(gdb) i r
eax            0xb7a12320       -1214176480
ecx            0xdc7f8f0        231209200
edx            0xb7a12320       -1214176480
ebx            0x1      1
esp            0xbfffebac       0xbfffebac
ebp            0xbfffebf8       0xbfffebf8
esi            0x11a80910       296225040
edi            0x11a2bba0       295877536
eip            0x672f4dec       0x672f4dec
eflags         0x10296  [ PF AF SF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

(gdb) x/10i &d_ret_code_dc
 0xb7a12320 <d_ret_code_dc>:  jmp    0x672f4dec
 0xb7a12325 <d_ret_code_dc+5>:        or     %cl,-0x2a97f3bb(%ebx)
 0xb7a1232b <d_ret_code_dc+11>:       insb   (%dx),%es:(%edi)
 0xb7a1232c <d_ret_code_dc+12>:       adc    $0xc308,%eax
 0xb7a12331 <d_ret_code_dc+17>:       add    %al,(%eax)
 0xb7a12333 <d_ret_code_dc+19>:       add    %al,(%eax)
 0xb7a12335 <d_ret_code_dc+21>:       add    %al,(%eax)
 0xb7a12337 <d_ret_code_dc+23>:       add    %al,(%eax)
 0xb7a12339 <d_ret_code_dc+25>:       add    %al,(%eax)
 0xb7a1233b <d_ret_code_dc+27>:       add    %al,(%eax)

(gdb) x/10i 0x08156ccc
 0x8156ccc <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem>: push   $0xb7a0b0bb
 0x8156cd1 <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem+5>:       ret
 0x8156cd2 <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem+6>:       mov    0xc(%ebp),%eax
 0x8156cd5 <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem+9>:       test   %eax,%eax
 0x8156cd7 <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem+11>:      mov    0x8(%ebp),%edx
 0x8156cda <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem+14>:      je
 0x8156f60 <GetEpicWeaponDevastatingCritical__17CNWSCreatureStatsP8CNWSItem+660>

I compared the content of instructions in d_ret_code_dc between running the module on my hosted environment vs my local environment, and it seems that the code being placed into there on the hosted environment is just garbage. As you can see, it wants to jump to a bogus address.

I had to comment out these Dev Crit hook changes to get things working again.

Working with some of the database stuff again, building on CentOS 6.4. When attemping to store/retrieve an object with SCO/RCO Using PostgreSQL I got consistent server crashes on double memory deallocations. On investigation, the escaping used was incorrectly formed, and the serialized object returned was not properly formed. It also appears that there is a bug in the server which results in freeing the buffer twice when the GFF package is malformed. Patching the code to use proper formatting solved the problem. Patch submitted.

There was an event for the pre-ee version of nwnx2 for Dev Crit. Here's some documentation from that repo.

It would help us out a lot if we could add this back in :)

Steps to reproduce:

• Starts a VM with ubuntu:xenial
• Upgrade VM to latest version
• Clone repository and cd into it
• Run cat apt-dep | xargs sudo apt-get install -y
• Run mkdir build && cd build
• Run cmake ..

You should run into this error:

Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)

The missing library is ZLIB, I think it's missing in the dependency file.

The makefile for the odmbc plugin attempts to build versions of the MySQL and SQLite plugins which link to the static database libraries (in addition to the dynamic linkage). Some linux releases, specifically RedHat/FedoraCore/CentOS, remove static libraries even from devel packages, so in order to build with static linkage you would first have to build the MySQL or SQLite client library yourself. Since most people don't build their own db client libs, the odmbc plugin build will fail on these platforms. This is a suggestion that the static builds be commented out in the default makefile with a note on building the static version if it is needed.