Giters

Tracktion / choc

A collection of header only classes, permissively licensed, to provide basic useful tasks with the bare-minimum of dependencies.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Spurious "User-mode data execution prevention (DEP) violation exception" on MemoryDLL destruction

JanosGit opened this issue · comments

commented

I gave the MemoryDLL a try lately and it worked well at a first glance.

Now, in a slightly more convoluted real-world setup it's causing "User-mode data execution prevention (DEP) violation" exceptions on application shutdown in debug builds now and then.

It occurs in a single threaded command line application. The exceptions are however thrown from additional threads not created by the application code but always happen to occur once the main thread is in the destructor of my MemoryDLL instance. Because of this timing and because the MemoryDLL obviously places some executable code in memory which seems what this exception is about I assume that these exceptions are related to the MemoryDLL class.

Still they only happen in e.g. 1 of 20 runs which makes it a bit hard to reproduce and until now they only occured in debug builds. Since the application where it's used is a company internal helper tool, I'm not worried as much about stability as I would if it was a in product code and I'm happy that this way to integrate the dll in the binary facilitates the deployment of that tool a lot. I just thought this could be interesting to you, so see this issue more as a heads-up than as a complaint ;)

If there is anything I could have done wrong to provoke that I'm happy to learn about it as well.

Thanks for sharing this great collection of helper tools!

commented

That's a tough one!

Bear in mind that a lot can still be happened after main() returns, so if your MemoryDLL object goes out of scope at that point, you could still potentially have other threads still running and using functions from it. Also, static destructors will get called after main(), so maybe those could end up calling a function from the DLL?

Maybe if you do have things using it later on, you should wrap your MemoryDLL in a ref-counted container, or make it a static variable rather than local to main()?

commented

Let me know if this is still an issue, or I'll close this ticket...

commented

Sorry for not updating this one, It went off my radar a bit.

In fact without changing anything to the code using the the memory dll, I never ran into this error again after reporting it, while actively developing the project where it's used in the last weeks. So it kind of stays there as an open question to me, but I'd close this now since I can't reproduce it anymore. I'd reopen the ticket in case this should come up again.

Thanks anyway for your help :)