"X strings remain in the string pool" failing tests

can you please double check if the problem still exists?

It works!

Good policy! Wait so long until the problem is hidden and does not show up anymore.

(The underlying problem is still there "string remaining in the string pool". It but it does not show up in this case but it shows up in many cases when I shut down Zorba).

I guess this would have been a good chance to track the problem down. But I guess this is too late now.

I have finally come up with a test case that reliably reproduces this problem. It occurs when you create a QNameItem using ItemFactory and pass a global zstring constant as the namespace URI. From stepping through with the debugger, it seems QNamePool puts the namespace URI zstrings into a StringPool, and ~StringPool doesn't like finding a zstring in there who is still marked as "shared" (which I think actually means "still has outstanding references"). Since the zstring is a global, it still has a reference outstanding at the time the store is shut down and ~StringPool is called.

I have added a unit test case which demonstrates this scenario, along with a slight variant that does not trigger the problem (if you create a new zstring wrapped around GLOBAL_ZSTRING.c_str(), it works fine). This is checked in on the branch lp:~zorba-coders/zorba/strings-in-pool. On this branch, test/libunit/qname_pool_global fails with this error, but test/libunit/qname_pool_local passes. (I have marked qname_pool_global as EXPECTED_FAILURE(), but since the test actually dies with an ABORT signal due to the assert, it still fails locally. It will pass on the validation queue, which does some post-processing for such cases.)

I can't swear this is the *only* cause of this problem, of course, but it is at least one, and one that specifically is biting me at the moment.

Given that this error is only occurring when the store is shutting down (and hence presumably the process is about to end anyway), perhaps a quick and dirty solution would be to simply eliminate the assert()? Is this really catching any errors that are serious enough to abort the program?

I have changed the global zstrings in staitc_context to const char* strings.