How does Run abort work

User forums > Using Code::Blocks

<< < (2/4) > >>

oBFusCATed:

--- Quote from: oBFusCATed on April 02, 2016, 05:35:58 pm ---I don't think this is the correct function:)

--- End quote ---
I was wrong. This is the correct function/method.

@tigerbeard: Usually you don't need a debugger to find what something does.
I've done it like this:
1. started from Build -> Abort.
2. search for Abort in the src folder.
3. you'll find that it is a menu item.
4. then you'll find the menu item's id - idCompilerMenuKillProcess
5. search for idCompilerMenuKillProcess in src
6. you find which function is called when this menu is selected

tigerbeard:
Very helpful answer, thanks.
After the initial surprise about the huge number of Abort hits I managed to find the location. Great. The killing is just a few lines, just as posted. However its helpful to see the bits around as well.

I am not sure what the purpose of that event is, does that influence the Kill below?

--- Code: --- #if defined(WIN32) && defined(ENABLE_SIGTERM)
::GenerateConsoleCtrlEvent(0, m_CompilerProcessList.at(i).PID);
#endif

--- End code ---

Basically that kill command in here

--- Code: --- // Close input pipe
m_CompilerProcessList.at(i).pProcess->CloseOutput();
((PipedProcess*) m_CompilerProcessList.at(i).pProcess)->ForfeitStreams();
ret = wxProcess::Kill(m_CompilerProcessList.at(i).PID, wxSIGTERM);

--- End code ---

should be doing the same as

--- Code: --- taskkill /F /IM MyApp.exe

--- End code ---

shouldn't it? But it does not and I can not see why. The code kill takes the app to hang for 1-2 secs before the Program stopped error is displayed. The console kill closes it instantly.

After the crash I get this output of Dr. MinGw. The only codeline from my app is IMPLEMENT_APP().

--- Code: ---Test.exe caused an Access Violation at location 6fe718d0 in module libstdc++-6.dll Reading from location 000000c8.

Registers:
eax=000000c4 ebx=00000000 ecx=000000c4 edx=00000000 esi=00000000 edi=0000003c
eip=6fe718d0 esp=0028fa9c ebp=0028fab8 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206

Call stack:
6FE718D0 libstdc++-6.dll:6FE718D0 _ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE5emptyEv
61D829F7 wxmsw293ud_gcc_custom.dll:61D829F7 _ZNK16wxAppConsoleBase17GetAppDisplayNameEv
61FD5F27 wxmsw293ud_gcc_custom.dll:61FD5F27 _ZNK8wxLogGui8GetTitleEv
61FD61DB wxmsw293ud_gcc_custom.dll:61FD61DB _ZN8wxLogGui5FlushEv
61DD6339 wxmsw293ud_gcc_custom.dll:61DD6339 _ZN5wxLog15SetActiveTargetEPS_
61DCBADD wxmsw293ud_gcc_custom.dll:61DCBADD _Z12wxEntryStartRiPPc
61DCBB48 wxmsw293ud_gcc_custom.dll:61DCBB48 _Z14wxEntryCleanupv
61DCBDE0 wxmsw293ud_gcc_custom.dll:61DCBDE0 _Z14wxUninitializev
623B5BE4 wxmsw293ud_gcc_custom.dll:623B5BE4 _ZN13wxInitializerD1Ev
61DCBC0D wxmsw293ud_gcc_custom.dll:61DCBC0D _Z11wxEntryRealRiPPw
61E49D74 wxmsw293ud_gcc_custom.dll:61E49D74 _Z7wxEntryRiPPw
61E4A062 wxmsw293ud_gcc_custom.dll:61E4A062 _Z7wxEntryP11HINSTANCE__S0_Pci
00443FB7 Test.exe:00443FB7 WinMain@16 Test.cpp:30
int32 WinMain@16(
HINSTANCE hInstance = &{
int32 unused = 9460301
},
HINSTANCE hPrevInstance = &{
int32 unused =
},
int32 nCmdShow = 10
)
...
//////////////////////////////////////////////////////////////////////
// 2010-03-08
> IMPLEMENT_APP(CTestApp)

...

005026CD Test.exe:005026CD operator+ gdicmn.h:560
struct wxPoint operator+(
struct wxPoint * p1 = &{
int32 x = 12529593,
int32 y = 0
},
struct wxPoint * p2 = &{
int32 x = ,
int32 y =
}
)
...
{
return wxPoint(p1.x + p2.x, p1.y + p2.y);
> }

inline wxPoint operator-(const wxPoint& p1, const wxPoint& p2)
...

004013E2 Test.exe:004013E2
768F33CA kernel32.dll:768F33CA BaseThreadInitThunk
76F49ED2 ntdll.dll:76F49ED2 RtlInitializeExceptionChain
76F49EA5 ntdll.dll:76F49EA5 RtlInitializeExceptionChain

--- End code ---

Tiger

PS interesting side detail in the code, why are you collecing all plugin events in a dispatcher. I can not really see the advantage not to list the functions in the event table?

tigerbeard:
Finally I found a way to get the debugger working with that scenario.
I just run two instances of CodeBlocks with the same project. The one starts the application.
The other attaches the debugger to the running process.

Works really nice.

oBFusCATed:
wxProcess::Kill(..., wxSIGTERM) is not the same as taskkill /F ..., probably it is the same as calling taskkill without /F.

See here: http://docs.wxwidgets.org/trunk/group__group__funcmacro__procctrl.html#gae3a7de5a29e70c77463dd1bc38fb98cf

GenerateConsoleCtrlEvent might help for console applications. But I doubt it is ever executed.

I'm a little confused by your last post. Can you explain in details what are you trying to do?

tigerbeard:

--- Quote from: oBFusCATed on April 03, 2016, 06:45:13 am ---wxProcess::Kill(..., wxSIGTERM) is not the same as taskkill /F ..., probably it is the same as calling taskkill without /F.
See here: http://docs.wxwidgets.org/trunk/group__group__funcmacro__procctrl.html#gae3a7de5a29e70c77463dd1bc38fb98cf

--- End quote ---
Unfortunately the docu just talks about Kill, not taskkill. Can only say from what I obverved from the behaviour that both taskkill and taskkill /F closed the application ok, the CB Abort button, aka the wxProcess::Kill did not. And from you feedback I take it that you would be surprised by different behaviour as well.

--- Quote from: oBFusCATed on April 03, 2016, 06:45:13 am ---I'm a little confused by your last post. Can you explain in details what are you trying to do?

--- End quote ---
I agree it can be a bit confusing by description in pieces only. Maybe that helps
I have this crash effect on application exit and have no idea what happens. I was just trying to find a way to reproduce it in the debugger. But since only the run abort from CB caused that crash, first I was looking for another way to cause that crash. My first idea was to find out what the abort button does and just do the same from the console.
With your help I can see now that CB does what you would expect, send a sigterm to the window. But that is exactly what I think the task manager kill and taskkill also do. But I still get that crash only with the Abort button version, not when stopping the App any other way.

The last post was about an alternative approach I did not see before. Its basically the way I can debug what the Build/Abort button does live. If you want I run the C:B debugging in parallel to CB running the application via the Build/Run command.

So now I can debug the problem. I did not find the bug yet, but I can see that I did not anticipate the way an application is closed by calling wxApp:OnExit() directly, i.e. before any windows know about the app being closed. But thats a pure wxWidgets programming issue and not C:B related.

To make a long story short. We can close that thread, because the issue itself is answered. I know what C::B does.
I still do not know why my App behaves differently between C::B Abort and taskkill but thats out of scope with this thread.
Should I find out sth which relates to C:B I shall add a short Info to this post.

Thanks for your help.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version