Yiannis was the one that performed the magic. But now I'm stuck with a bug report, and have no idea what to do with the rpt file :-( Does anyone know?
the most interesting thing in the .rpt file is that you find the callstack up to the crash
so walk the callstack down until you find an entry which references to a function which
is coded in the sourcecode of codeBlocks - voila, you know the function which has triggered
the GPF
- the rest you've to manage with a debugger of your trust :shock:
UPDATE
codeblocks.RPT
Error occured on Friday, August 5, 2005 at 01:16:01.
D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.exe caused an Access Violation at location 1010d520 in module C:\UTILS\wxmsw242.dll Reading from location 00000028.
Registers:
eax=00000000 ebx=00252354 ecx=6064cb3d edx=00000000 esi=00001799 edi=0022e31c
eip=1010d520 esp=0022f7d8 ebp=0022f7e8 iopl=0 nv up ei pl nz ac po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010216
Call stack:
1010D520 C:\UTILS\wxmsw242.dll:1010D520 _ZN12wxWindowBase10FindWindowEl
605055BC D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.dll:605055BC EditorManager::EditorManager(wxWindow*) D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/sdk/editormanager.cpp:127
60504873 D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.dll:60504873 EditorManager::Get(wxWindow*) D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/sdk/editormanager.cpp:93
605214D5 D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.dll:605214D5 Manager::GetEditorManager() D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/sdk/manager.cpp:228
0041131D D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.exe:0041131D MainFrame::CreateIDE() D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/src/main.cpp:455
0040F70A D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.exe:0040F70A MainFrame::MainFrame(wxWindow*) D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/src/main.cpp:369
00402586 D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.exe:00402586 CodeBlocksApp::InitFrame() D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/src/app.cpp:176
00402E8C D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.exe:00402E8C CodeBlocksApp::OnInit() D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/src/app.cpp:250
10015272 C:\UTILS\wxmsw242.dll:10015272 _Z7wxEntryPvS_Pcib
00401392 D:\cpp\_projects\Codeblocks\_VERSION_1_0\src\devel\codeblocks.exe:00401392 WinMain D:/cpp/_projects/Codeblocks/_VERSION_1_0/src/src/app.cpp:40
...skip the rest...
1.) Reading from location 00000028.
some pointer contained this value and it is a protected address
2.) callstack
WinMain called ..some others... until
Manager::GetEditorManager() called
EditorManager::Get(wxWindow*) which called
EditorManager::EditorManager(wxWindow*) and then it crashed in
WindowBase10FindWindow
now look in the source code, the line numbers are given in the call-stack too:
editormanager.cpp
125: // *** Load Panel and close button from XRC ***
126: m_pPanel = wxXmlResource::Get()->LoadPanel(parent,_T("ID_EditorManagerPanel"));
127: wxBitmapButton* myclosebutton = XRCCTRL(*m_pPanel,_T("ID_EditorManagerCloseButton"),wxBitmapButton);
so it's most likely that the parameter m_pPanel was invalid at the time of crash,
it was retrieved in line 126 but not checked for validity and used in line 127.
3.) forget the Registers, until you are not programming in assembler and set the registers "by hand"
or you win chess games against Deep-Blue 8) and compile a 1000+ lines sourcecode with your brain not using a compiler,
like the heroes in the 1970ies did, when they developed the first microcontrollers...
ARGH! Well, thanks for the info :)
Um... the codeblocks.rpt I got hasn't gotten any line information... only addresses.
Quote
Call stack:
100AD5A1 C:\Program Files\CodeBlocks\wxmsw242.dll:100AD5A1 _ZN10wxListBase10DetachNodeEP10wxNodeBase
100AD91E C:\Program Files\CodeBlocks\wxmsw242.dll:100AD91E _ZN10wxListBase10DeleteNodeEP10wxNodeBase
6062F5FE C:\Program Files\CodeBlocks\codeblocks.dll:6062F5FE _ZN11EditorsList10DeleteNodeEP17wxEditorsListNode
605092A0 C:\Program Files\CodeBlocks\codeblocks.dll:605092A0 _ZN13EditorManager5CloseEP10EditorBaseb
60509167 C:\Program Files\CodeBlocks\codeblocks.dll:60509167 _ZN13EditorManager5CloseERK8wxStringb
604D5EE9 C:\Program Files\CodeBlocks\codeblocks.dll:604D5EE9 _ZN9cbProject13CloseAllFilesEb
Quote from: rickg22 on August 05, 2005, 08:13:55 PM
Um... the codeblocks.rpt I got hasn't gotten any line information... only addresses.
then you have got a rpt file from a stripped version of codeblocks
use the /devel/codeblocks with debug symbols in it to get symbolic information in the rpt
Quote from: tiwag on August 05, 2005, 08:16:33 PM
use the /devel/codeblocks with debug symbols in it to get symbolic information in the rpt
And how exactly do i do that? the .rpt file wasn't generated by me but by the bug submitter.
Quote from: rickg22 on August 05, 2005, 08:17:34 PM
Quote from: tiwag on August 05, 2005, 08:16:33 PM
use the /devel/codeblocks with debug symbols in it to get symbolic information in the rpt
And how exactly do i do that? the .rpt file wasn't generated by me but by the bug submitter.
that's a dilemma - :shock: - it only works with the debug-version
the adresses are different with & without debug symbols,
so you can't look easily which adress corresponds to each version.
moreover you would need map files of each dll ... a horror - normally it isn't worth the expense
can't you send the submitter a development debug-version of codeblocks?
or try to reproduce the crash with your debug-version.
Then I think we have to strip the strip command from the update file and always release debug versions, except when we know the version is bug free :)
Good idea :P
Quote from: rickg22 on August 05, 2005, 08:17:34 PM
Quote from: tiwag on August 05, 2005, 08:16:33 PM
use the /devel/codeblocks with debug symbols in it to get symbolic information in the rpt
And how exactly do i do that? the .rpt file wasn't generated by me but by the bug submitter.
There is a nice command line utility called addr2line. Surprise! It can decipher the reported address and map it to source file and line!
How to use it (based on your example rpt):
1) You must be doing this with the exact same C::B build (with that of the user that sent you the .rpt) or the info will be garbage
2) Go to *your* devel folder (where the unstripped .exe and .dll resides)
3) Issue "addr2line -s -e codeblocks.dll 605092a0" (The module and address reported in "605092A0 C:\Program Files\CodeBlocks\codeblocks.dll:605092A0 _ZN13EditorManager5CloseEP10EditorBaseb")
4) The prompt returns with:
editormanager.cpp:704 :D
5) Rinse and repeat (3) for the rest of the lines you want to decipher.
See? No need to ship debug versions ;)
Yiannis.
PS: addr2line is part of binutils IIRC and is included with the C::B/MinGW bundle.
Does it work with plugin dll's?
Quote from: rickg22 on August 19, 2005, 08:44:17 AM
Does it work with plugin dll's?
Yes, it works with everything you have debug versions of ;)
Yiannis.
and the addresses stay the same after stripping ?
so you can use the address of the function of the stripped executable to find the symbol in the debug version ?
Quote from: tiwag on August 19, 2005, 09:41:00 AM
and the addresses stay the same after stripping ?
so you can use the address of the function of the stripped executable to find the symbol in the debug version ?
Correct, stripping just strips the debug info (filename, line number, etc). It can't strip addresses!
Yiannis.
Quote from: mandrav on August 19, 2005, 12:03:21 PM
Quote from: tiwag on August 19, 2005, 09:41:00 AM
and the addresses stay the same after stripping ?
so you can use the address of the function of the stripped executable to find the symbol in the debug version ?
Correct...
fine, i thought the function-addresses (at least the local defined ones) would change their value after stripping...
However it'd be nice to have an "rpt_addr2line.exe" that would give us a decyphered codeblocks.rpt...