Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
[deleted comment]
Your solution likely introduces a memory leak.
CXAPOBase, which is the ultimate parent of XAPOBaseImpl, takes
XAPO_REGISTRATION_PROPERTIES* but it's not clear if it expects those properties
to live beyond the constructor invocation -- the documentation doesn't say.
If it does, we should store a copy of the properties in the XAPOBaseImpl
object. If it doesn't, the bug is probably elsewhere.
Original comment by josh.petrie
on 7 Dec 2010 at 4:38
Mike presumably knows more about this, I've never done anything with this API.
Original comment by josh.petrie
on 7 Dec 2010 at 4:40
Hello Josh,
Thank you for a quick response...
I didn't meant this to be a final solution - I am a complete newbie in SlimDX,
so I know nothing about it's internal implementation concepts, and I am even
not very skilled in C++ programming, so I published this more as the proof of
my theory about the problem with local variable.
It fixed the XAPO_REGISTRATION_PROPERTIES corruption in my case - and I think
this is also the answer to your question, whether the properties are expected
to live beyond the constructor: I am quite sure they must live beyond, because
the XAPO is being asked about them during SetFilterChain() call...
Original comment by david.sv...@gmail.com
on 7 Dec 2010 at 6:29
This issue was closed by revision r1793.
Original comment by Mike.Popoloski
on 11 Dec 2010 at 8:25
I made the fix. Let me know if it resolved your issue.
Original comment by Mike.Popoloski
on 11 Dec 2010 at 8:26
Hi Mike,
I've tried it, and it seems to behave well, now... Thanks a lot!
David
Original comment by david.sv...@gmail.com
on 15 Dec 2010 at 6:30
Glad to hear it.
Original comment by Mike.Popoloski
on 15 Dec 2010 at 6:41
Original issue reported on code.google.com by
david.sv...@gmail.com
on 7 Dec 2010 at 3:26