Access violation when closing application

[doggrant]

Hi,

I've got a very strange issue. Where by when running my application under the debugger I get an access violation when everything is being cleared up.

However, if i run it outside of the debugger, in either release or debug mode, it exits cleanly.

When my app closes, the destructors for various objects are called. In one of my destructors I have this code, which signals to an external thread, to stop, and then waits for that thread to exit - I do this with an event loop, so as not to freeze the GUI



// A ten second timeout, to wait for the hotswap thread to exit
// If it takes longer than this, then we'll just kill it off.
QEventLoop EventLoop;
QTimer WatchdogTimer(this);
WatchdogTimer.setSingleShot(true);
connect(&WatchdogTimer, SIGNAL(timeout()), &EventLoop, SLOT(quit()));
connect(this, SIGNAL(finished()),&EventLoop, SLOT(quit()));
WatchdogTimer.start(10000); // 10s timeout

// Signal hostswap thread quit before entering event loop
osSignalWaitObject(m_Terminate_hot_swap_thread);

EventLoop.exec();


As I said, when the code is run in the debugger, I get an access violation when stepping over 'EventLoop.exec();'

7475

Has anyone come across this issue before?

David

[MarekR22]

Event loop in destructor! This is bad idea. You will never know what will happen in this event loop, maybe some slots for this object are called corrupting destructor data.
Anyway if application is closing why you need this event loop? waitFor for the thread should be ok and more safe.

Why it is crushing it is hard to tell without wide context of code.

[high_flyer]

On which line in your code do you get the access violation?


P.S
Its hard to say without knowing your full project, but the way you are doing things seems dangerous and rigid.
Since it seems you have a complex cleaning up which requires waiting, I would put that functionality in an object responsible only for cleaning up (and that class in its own thread).
(this way you keep good design principals - in this case mainly "Single Responsibility Principle")
It will free you from such "acrobatics" as you are doing with the event loop.

[doggrant]

Hi,

I've got a bit further on this issue. I've removed the eventloop, and just have my event signalling to stop my thread:


osSignalWaitObject(m_pCard_Page_HS_Manager->m_Terminate_hot_swap_thread);

which is an os independent waitobject wrapper.

It would seem that as soon as I exit the run() method for my class, I get the access violation. Does anything specific happen when you exit the run() method of a qthread class?

regards,

David

[doggrant]

Does anyone have any further thoughts on this issue?

[high_flyer]

The information you supplied is just not enough to say if this is a design problem or not.
But it seems to me its more likely an implementation error - which is really hard for someone not familiar with your code to locate.

[wysota]

The error suggests you are trying to dereference a pointer that is null. Getting a debugger backtrace should help pinpoint the problem.

[doggrant]

I tried getting a backtrace, but there is no stacktrace visible just after the failure occurs, which i find very strange. I am currnetly at a loss how to proceed with this issue.

[wysota]

What do you mean there is no stacktrace visible? Visible where? Did you ask the debugger for the trace? What did it say?