Hello,

I'm using H3D 2.2 beta and trying to programmatically set up some custom URNs for my application, but I'm getting some very weird behavior from ResourceResolver. Here's some sort-of pseudocode that illustrates the problem:



I get the following output:



I expect ResourceResolver::resolveUrlAsFile() to have the same output as URNResolver::resolveURN(), but it doesn't. After running this code in a debugger, I see that inside the call to resolveUrlAsFile(), the call to urn_resolver().get() always returns zero, even though clearly the AutoRef<> object *does* contain a valid pointer.



Of course, this has me very confused. Am I somehow misusing ResourceResolver and/or URNResolver?

My toolchain is MinGW GCC 4.6.2 on Windows 7. I understand that MinGW is not an officially supported compiler (and that is why I haven't reported this on the bug tracker), but I haven't had any problems with a MinGW-built libH3DAPI.dll up to this point. Is it possible I've run into a compiler bug? Presumably, wouldn't people using GCC 4.6.2 on other platforms have the same problem (assuming they're trying to use URNs)?

I did mention that I'm using the 2.2 beta branch of H3D, but the ResourceResolver code seems unchanged from the 2.1 branch, so I assume I'd have the same problem there.

Any thoughts on this issue are greatly appreciated. I'm more than willing to try out any patches folks might come up with.

Thanks,

- Karl

I am guessing that H3D::initializeH3D() in H3DApi.cpp for some reason is called after you already set a new urn-resolver. Could you check that this is not the case?

Other than that I can only suspect some assumed static initialization order or something along that road.

How did you debug that it never enters

cerr? step into (if that is possible with ming)? or somehow else?

Quote:

I'm using GDB 7.3.1 from MinGW and set a breakpoint.

Quote:

H3D::initializeH3D() is being called only once, on program start-up.

Quote:

It does look like some sort of static initialization problem. I set a breakpoint in ResourceResolver::urn_resolver() in ResourceResolver.h to see what the value of urn_resolver is after each call:



It seems that when the call to urn_resolver() comes from ResourceResolver::getURNResolver(), things work as expected. However, the direct call to urn_resolver() from ResourceResolver::resolveURLAs() either causes the static urn_resolver instance to be re-initialized, or it's returning an entirely new instance.

EDIT: Adding another call to ResourceResolver::getURNResolver() after the call to ResourceResolver::resolveURLAs() returns my original URNResolver instance! So it appears that the call to urn_resolver() in ResourceResolver::resolveURLAs() *does* in fact return a new URNResolver instance.

Any ideas for workarounds? It seems to me that the motivation for putting the urn_resolver static initialization into ResourceResolver::urn_resolver() is so that subclasses of ResourceResolver have their own distinct static instance of URNResolver. Is there a way to move to static initialization somewhere else without breaking things?

Thanks,

- Karl

SECOND EDIT: I created the following workaround:


Since I only need one URNResolver instance in my application, this works just fine.

To me it seems like a bug, only one urn-resolver should exist.
Could I bother you to create a short test case and submit a bug report?

Yes, I will put together and submit a test case against H3D trunk, since the ResourceResolver code is the same as in 2.2 beta.

The patch above seems to revert a patch I sent you to fix a "Static initialization order fiasco". The static auto_ptr might not have been initialized when first used, and might seem to point at a valid object since it has not yet been set to NULL.

----------------
KJ Lundin Palmerius
C Research
Linköping University, Sweden

Quote:

My forum notifications and inbox are empty, so I don't think I ever received the patch you sent. Or did you send it via email?

I agree that in my example patch I do not initialize the static auto_ptr properly. I've edited that post accordingly.

I miswrote, thought I replied to Markus. The patch was sent to SenseGraphics and implemented the function static variable as a remidy to the static initialization order problem.

The initialization cannot be global since there are other objects created globally that rely on the resolver already being initialized at that point. It was only when I updated the compiler that the problem appeared.

----------------
KJ Lundin Palmerius
C Research
Linköping University, Sweden

Ok, I think I have the problem worked out.

I believe that having the ResourceResolver::urn_resolver() method definition in class scope was causing it to be inlined by GCC. This in turn results in two separate "copies" of the inlined urn_resolver() method -- one in H3DAPI, and one in my code. Calling getURNResolver() returns my URNResolver instance, but the call to resolveURLAs() returns the "copy" owned by H3DAPI.

This patch fixed things for me:


I can still submit a test case demonstrating the old behavior to the Mantis tracker, but given the trivial nature of the patch, it seems unnecessary to me (and I can't imagine that this patch would break things for other compilers).

Should I submit a test case along with this patch, or just the patch itself?

Many thanks,

- Karl

The patch will be fine in this case. If you refer to this forum post in your bug report it would be good, for more information.