NWNX ODBC2 object storage engine

[JeroenB]

Ok, I have tested the plugin and demo module a bit too. I noticed the following things:

* Make sure that you alter the SQL query in the demo_obj_create script to match your database. So if you are using MySQL comment the SQLite part and uncomment the MySQL part.

* When using version 4.0.x make sure you also alter the table creation statement to match your version. For 4.0.20a that will be:

[Papillon]

I will modify the create statement so it works for both versions. I did not know there was a difference.

Earandel, I did the same test, malloc'ing new memory every RCO call, but it did not help. Every time after the second RCO, the test computer would crash. Btw, I found out that arg5 actually is the return size of the object, so my function now looks like this:

[Senalaya]

Let me recap, what you tried so far, Papillon.

Version I (original)
When RCO is fired,
- if a pResult is still a valid pointer, it gets deleted.
- a new byte-pointer gets created with the actual DB-object size.

Version II (no-delete)
When RCO is fired,
- a new byte-pointer gets created with the actual DB-object size.

Version III (static)
A static byte-pointer, with a fixed size of 1MByte, gets created when the dll is loaded.
When RCO is fired,
- the DB-object is copied into that static area.

Further, you said that arg5 is a a size variable, which gets overwritten with the actual size of the DB-object, correct?

IMO, that'd leaves 2 possible uses for arg4:
- It could be a kind of flag variable, so setting it to 0 might be worth a test.
- Or, taking from it's position in the arg list, it could for some reason be used, to return the pointer to the DB-object again.

In that latter case, exactly this variable could be used on Bio's side, to call the 'delete', so testing versions I & II again would make sense.

[Blacksting]

I have come late to the crashing party. I did not have any problems with crashes on my test server. Days of development and converting current Bio DB systems to SCORCO hooked ones went by without a crash. When I moved everything to the actual server RCO (on my initialization of persistent creatures routine on module load) crashes the ntdll.dll. I was reading briefly through the latter half of this thread but did not come across a mention of what .dll is crashing for everyone else. Is the ntdll.dll crash something different from what you are talking about so far?

[JeroenB]

Do you have WinSock 2 installed on your machine? If not try installing that and see if that solves the problem (or make sure your have XP service pack 2).

[Papillon]

Senalaya, the problem is that ODBC2 allocates the dynamic object memory on a certain heap, while NWN uses another heap. That confuses the hell out of the older ntdlls, while the newer from service pack 2 does not seem to have troubles with that. It worked without crashes when I allocated my memory on the same heap NWN uses, the problem is to find out which heap to use. There is a static pointer in the server that points to the right heap, unfortunately, the location of this pointer will change with every new compile of the server and thus would make ODBC2 extremely version dependent. There is also another thing that makes me wonder. Seemingly, the memory NWN allocates point to some high memory region (like 0x0700000), while the heap for allocation and deallocation is relatively low (like 0x036000). I am not sure yet what this means, but probably there is more to it.

All in all, for now the static method will have to do, since everything else would involve lots and lots of additional work.

Blacksting, the crashes in ntdll is what we are talking about. Get test -test version or the soon-to-be-available 0.9.2.3 for a static version that does not crash on older operating systems.
_________________
Papillon

[dragonsong]

How about an option in nwnx.ini for configuring how much memory to allocate? Or even (use-at-your-own-risk) a setting for using either static or dynamic?

I'd think statically allocating might even be more efficient, if the mod is going to make frequent use of the redirector, and only at the cost of a little more memory up-front. (Something a busy server should be able to spare.) Yes? No?
_________________
- dragonsong

[Papillon]

When I say statically, I really mean it Every chunk of memory allocated by a parameter coming from the ini file is inherently dynamic. No, it has to happen at compile time.
_________________
Papillon

[Asmodae]

Does this mean the crash bug has been eliminated? I'm guessing so from the posts, but I'm anxious to know for sure.
_________________
Nepenthe - An NWN2 Persistant World, coming to a planet near you. http://www.nepentheonline.com

[dragonsong]

Well, the tweakers will just have to recompile, I guess.

Now, give us an ETA for OnSCO!
_________________
- dragonsong

[Papillon]

Asmodae, I have no reports of crashes with SCO/RCO in ODBC2 0.9.2.3, so it seems to work everywhere now.

dragonsong: ok ok
_________________
Papillon

[Asmodae]

WHEEEE! Thanks guys. Work and school are both hammering me right now, but I'll get this and give it a try as soon as I can.
_________________
Nepenthe - An NWN2 Persistant World, coming to a planet near you. http://www.nepentheonline.com

[NoMercy]

Works fine for me, under MySQL and SQLite... though if MySQL isn't running it crashes nwserver :/

[Papillon]

Apparently, there are still some rough edges in the MySQL portion of ODBC2. I will go over that module next weekend and see what else I find...
_________________
Papillon

[Papillon]

I fixed the crash if MySQL is not loaded and a couple of other small things in version 0.9.2.4.
_________________
Papillon