Switch to this thread crashes

[Multinode Nick]

Hi,

It's my first Code Blocks day, it seems to be a really promising IDE so I'm testing it every way I can to be sure to choose a best IDE for my development team and I for the next years.

I think I just felt on an application bug by trying basic multithread functions.

I coded a simple thread function in a Win32 project:

DWORD WINAPI CommunicationFct(LPVOID param)
{
    int i =0;
    while(1)
    {
        i++;
        Sleep(100);
    }
    return 0;
}

I create 4 threads with these calls:

CreateThread(NULL,0,CommunicationFct,NULL,0,&dThreadID);
CreateThread(NULL,0,CommunicationFct,NULL,0,&dThreadID);
CreateThread(NULL,0,CommunicationFct,NULL,0,&dThreadID);
CreateThread(NULL,0,CommunicationFct,NULL,0,&dThreadID);

The software works fine and in debugging mode, the 4 threads appear in the "Running Threads" debug window.

But if I stop debugging, the threads are still available in the GUI and if I click on "Switch to this Thread", the whole IDE crashes. Not a really bad bug, but a bug and possibly easy to fix.

Should I report it to the official Bug reporting services?

Thanks

[MortenMacFly]

Confirmed. This is the back trace (rev. 3155).
Will have a look into... the expert should be mandrav.
With regards, Morten.

Edit: Reason is access to a NULL object (m_pDbg->GetState().GetDriver() returns NULL because the driver isn't active anymore). Will fix the crash, but the listbox shouldn't have content at that time... mandrav?

Edit2: Fixed in revision 3173.

[attachment deleted by admin]

[mandrav]

but the listbox shouldn't have content at that time... mandrav?

Yes, all debugging windows should be cleared when the debugging session ends.

[MortenMacFly]

Yes, all debugging windows should be cleared when the debugging session ends.

Ok - I had a look into it. I implemented cleaning all debugging windows in the destructor of DebuggerDriver::~DebuggerDriver(). But then I realised that this would also clear the backtrace (BacktraceDlg) which makes no sense. So I took that off. Then I realised that it may make sense to keep the DisassemblyDlg, too. After that came the ExamineMemoryDlg, CPURegistersDlg... in the end I think it is OK just as it is because this might still be valuable information even if the debugger has stopped. It just shouldn't crash when "clicking on it".
Yiannis: Do you agree?
With regards, Morten.

[mandrav]

Yiannis: Do you agree?

Yes.