Resman stability and dynamic .jrl file

[leo_x]

If it ever points to anything different than fileInfo.data it would be to a script loaded by resman and stored in one of the KeyTable's internal CRes structs. So, supposing that's the case -- and it might not be -- then at least you'd have an upper bound on what you could leak: scripts added to physfs after they'd already been loaded by CExoResMan would leak once.

I'll take a look again this weekend, but that it works without crashing is probably the most important thing.
_________________
the awakening (PW Action)

[elven]

[elven]

In case you decide to work on this some, there's another issue.

Sometimes, it stops serving script files over physfs (didn't test anywhere else).

Quite suddenly, spell scripts stop working, no other scripts are being called. SOME still work though, like event handlers for for nwnx_events or _chat.

This here should have ExecuteScript()'d another, but it never did. What stumps me is the all-zero fields.

[farhorizon]

Sorry for slight off topic, but is it safe to use the resman so from earlier in this thread to address crashing issues in the standard resman plugin?

Based on my reading, it wouldn't require the physfs so, correct?

[elven]

I have been using some older version of resman for a long time with no crashes and minimal memleaking, yes. Not sure if it is the one posted earlier.

[elven]

@problem above: Original resman has the same issue.

[leo_x]

Weird, is the size right? I noticed when I updated that I'd sometimes get script error... invalid bytecode. But that it would resolve itself maybe when the file size changed. The directory part of physfs is just a light wrapper of the normal OS filesystem operations.

m_nID being zero means it's not indexed in a key table, I guess it's normally a hash of the resref, which explains m_pKeyEntry being 0 because that's a NULL pointer that'd point back to the the actual key table entry had it existed.

How much memory is the server leaking?

@farhorizon if you're not serving scripts from resman that aren't somewhere in your module, hak, or a bif, I think the one in the master repository works fine. I wouldn't use the one I posted earlier, because it's never going to be worked on again. I'll edit that post.
_________________
the awakening (PW Action)

[elven]

It's a really weird thing, goes like this, and it happens both with upstream resman and nwnx_resources+physfs:

I can click-spam store "A" which works exactly 7 times - loading dlg, utm, and some utis. The 8th time, resman doesn't even see the request for the .dlg anymore, and the dialogue doesn't open. At the same time, most scripts stop working.

Meanwhile, in the same situation, i can click-spam store "B" and suddenly "A" stops working, while B still does. Note that stores are re-created on each click, so they're not left in the area.

Most cached scripts still work (like NWNX event handlers), but new scripts are not found (and resman does not see the request to handle them either).

I've tested this with only resman and no external providers, it still fails.

This behaviour didn't happen before, even though I am running original upstream code. The only thing changed is that I load areas from resman now, and all game resources are either in resman directly, or in redis which talks to resman via pluginlink.

*scratchy-heady*

Returned file sizes are correct in both accounts. I got the script errors too, and they might be related to the internal nwserver cache. Not sure. They never were a problem that looked like this, only on first invocation after updating.

Memory leaks are not what I'm worried about right now - considering I've switched back to the upstream resman. It looks like it's about 10MB/h.

[leo_x]

Honestly, it's this kind of random crap that put a damper on my enthusiasm for the project and pretty much any NWNX stuff except my Lua plugin.

The virtual machine does bail out when when the script recursion level is great than 7 right at the start of CVirtualMachine::ReadScriptFile... but why on earth that would be happening because of resman? And why would it only affect some scripts?
_________________
the awakening (PW Action)

[elven]

I can understand. As I said, it's not script files as such, it's ANY ref that is loaded after the fact.

I'll see about getting a testcase/env up ..

[leo_x]

Oh, I just assumed it was the onconv script blocking the BeginConversation from loading the dlg. Say, if you relogged with a different toon would the UTI for the equipment be bypassed?
_________________
the awakening (PW Action)

[elven]

[leo_x]

Well the script wouldn't get demanded if it's the recursion level issue.

No clue what I was thinking there, sorry.
_________________
the awakening (PW Action)

[elven]

Oh, get it.

Though I don't see how I can even reach 7, assuming it works the way I think.

* nwnx_events calls msg_chat

* msg_chat does some parsing on "/*" and calls cmd_*.ncs.

That'd be recursion level 0->1, right?

I don't see how clicking on a NPC to trigger a simple conversation be at 7 unless it wouldn't reset for some reason.

And, similarily, why this would fail on NPC A, but then (even after triggering the issue) still work on B (where nw_c9_conv or whatever still fires and runs the dlg + merchant) - more than 7 times, too.

This sucks.

[leo_x]

Yea, no clue why it would happen it doesn't make sense either way . Recursion level would be bumped everytime ExecuteScript is called, so really I have no idea why that would cause anything, but the return value of that function would be an easy place to start.

I don't know that it would be an issue with that per se, but maybe memory corruption?

Maybe I'm missing it, but I honestly can't see any other way a script wouldn't hit the resman hook.
_________________
the awakening (PW Action)