Skip to Content.
Sympa Menu

mace-opensaml-users - RE: [OpenSAML] marshalling problem C++

Subject: OpenSAML user discussion

List archive

RE: [OpenSAML] marshalling problem C++


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: [OpenSAML] marshalling problem C++
  • Date: Mon, 12 May 2008 23:19:55 -0400
  • Organization: The Ohio State University

> 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);

It's not fun tracing that stuff. What I was after was whether at some key
points within the top level marshall() call, is the pointer valid?

> 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.

Any call meaning any call you make, right? There are a ton of calls inside
marshall().

> 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."

That isn't 100% definitive. Are you able to step into Xerces? If not, you're
not getting a clear debug read I don't think.

> I've rebuilt xmltooling at least twice.

I meant everything. Xmlsec, xerces, all of it.

> 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?

I don't know what else to tell you, this is too "elemental" (forgive the
pun) to be anything but environmental. Either that or it should have been
failing before, none of that code has materially changed recently.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page