OpenSAML user discussion

["Brian Sheely" <>]

Okay, I rebuilt everything again in debug mode and set a breakpoint on 
        DOMElement* element = request->marshall();
There are hundreds of subsequent calls to step into starting with
        AbstractDOMCachingXMLObject::releaseChildrenDom(false);
Based on the call stack, all of the subsequent calls are in xmltooling, 
log4shib, and msvcp80d (most in xmltooling). The resulting pointer definitely 
points to a DOMElement object (the compiler is able to successfully cast it 
to a DOMNode*), but any call on it causes a crash. As far as setting a watch 
on element during a debug run, as soon as it comes back into scope and the 
assignment is made, its vtable values "cannot be evaluated." 

I've rebuilt xmltooling at least twice. Other than setting include and 
library paths, there's not much to change so I don't see how the build could 
be messed up. The fact that all of this code has worked perfectly so many 
times in the past makes things even more confusing. Needless to say, I'm 
completely in the dark. Any ideas? If not, I assume my next step would be to 
become familiar with xmltooling and continue debugging?


Brian Sheely
Software Engineer

Clareity Security 
10420 Jackson Oaks Way
Suite 201
Knoxville, TN 37922

Office: (865) 769-0456 x606
Fax: (865) 671-6630
Web: www.ClareitySecurity.com




-----Original Message-----
From: Scott Cantor 
[mailto:]
 
Sent: Friday, May 09, 2008 5:23 PM
To: 

Subject: RE: [OpenSAML] marshalling problem C++

> Code which seemed to work perfectly several months ago, now has a problem
> with marshalling.  None of my code has changed since then and is shown
> below. The pointer returned from the marshall call isn't NULL, but it
> doesn't point to a valid DOMElement.

Not possible, obviously, so I have to assume this is a build issue.

> I recently updated to the latest
> versions of saml2 and xmltooling. Other third-party libs are the most
recent
> versions which I used previously. It may be worth noting that not calling
> set methods on AuthnRequest doesn't change the result.

That code isn't materially different than what I use all over, so it isn't
the code. What do you see if you trace it? The debugger should be able to
get into Xerces, and see that it's got a DOMElement inside the marshalling
code, so when does it become invalid?

> Strangely enough, if I run against the saml2 and xmltooling DLLs which I
> think I used previously, I crash while trying to marshall the response.
That
> code is shown below.

Well, I don't know what those are and plugging in a different set is just
never going to work, so I don't think it's worth worrying about.

I would start by rebuilding every inch of everything.

-- Scott