Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Search in Files

(1/1)

Ceniza:
I just tested that feature in Code::Blocks CVS (29-Jun-05), compiled with wxWidgets 2.6.1 and it crashes lovely.

I compiled it without debug symbols so I cannot point to the right place it's happening, even though the crashing error is:

codeblocks.exe caused an Access Violation at location 0050b50c in module wxmsw26_stc_gcc_custom.dll Reading from location 00000000.

In other words, trying to read a NULL pointer inside STC.

Another way to implement that feature, as I've seen in other editors, is calling grep. It could be considered.

I would also like to corroborate the error is really happening so, anybody else willing to crash it?

mandrav:

--- Quote ---I compiled it without debug symbols so I cannot point to the right place it's happening, even though the crashing error is:

codeblocks.exe caused an Access Violation at location 0050b50c in module wxmsw26_stc_gcc_custom.dll Reading from location 00000000.
--- End quote ---

If you built from sources, then the devel folder holds a copy (the initial build output actually) which has debugging symbols. Maybe if you tried with that?

Yiannis.

Ceniza:
Hmmm, there was nothing when I made the cvs checkout.

I guess I'll have to recompile with debugging information 'cause now I'm getting an even worse problem that crashes Code::Blocks (I'm still trying to find the reason, but it has something to do when I switch to another application and go back to Code::Blocks).

mandrav:

--- Quote ---Hmmm, there was nothing when I made the cvs checkout.
--- End quote ---

OK, here's the process outline:
[*]Checkout CVS
[*]Build C::B using the makefile or the .cbp
[*]At this point C::B is built under devel/
[*]Run update.bat
[*]At this point C::B is copied under output/, resources packages are created and debugging symbols stripped[/list:u]

Note that the stripping is done only under output/
So, if C::B crashes for some reason, try running it from the devel/ directory where it contains debugging symbols.
After the crash, a file codeblocks.rpt will be generated containing stack info. If you don't delete this file, all future crashes will append to it, so the last section will be the most recent.

HTH,
Yiannis.

Ceniza:
Ok, recompiled Code::Blocks without stripping (that's why I hadn't one with debugging information) and retried Find in Files.

I opened a project and 1 file of it. Ctrl+F, Find in Files (Scope: Project files) and this is the backtrace by GDB (I typed bool as the string to find):

Program received signal SIGSEGV, Segmentation fault.
0x0050b50c in wxStyledTextCtrl::SendMsg ()
   from D:\WINDOWS\system32\wxmsw26_stc_gcc_custom.dll
(gdb) bt
#0  0x0050b50c in wxStyledTextCtrl::SendMsg ()
   from D:\WINDOWS\system32\wxmsw26_stc_gcc_custom.dll
#1  0x0050eaa9 in wxStyledTextCtrl::SetText ()
#2  0x0051287f in wxStyledTextCtrl::LoadFile ()
#3  0x6052f96a in EditorManager::FindInFiles ()
   from D:\Documents and Settings\Ceniza\cvs\codeblocks\src\devel\codeblocks.dll

#4  0x01a57680 in ?? ()
#5  0xffffffff in ?? ()
#6  0x104fbd50 in ZZN20wxSimpleHelpProvider8ShowHelpEP12wxWindowBaseE11s_tipWind
ow ()
#7  0x104fbd58 in wxDefaultPosition ()
...

I hope it be useful.

Navigation

[0] Message Index