Actually, it comes up whenever I'm clicking on a wxSmith.cbp project now. Maybe it has something to do with:
Compiling: app.cpp
Linking executable: wxSmithproject.exe
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.4\..\..\..\..\mingw32\bin\ld.exe: cannot open output file wxSmithproject.exe: Permission denied
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 23 seconds)
0 errors, 0 warnings
And wxSmithproject.exe is in the Task Manager (but not in the task bar -- looks like it didn't exit cleanly for whatever reason).
I'll check that in a second. But the gdb thing seems like a bug:
I create a new wxWidgets project, compile it, run it, no problems. Then goto debug->start and it brings up the wxWidgets sample app main window. When I close that gdb does not exit. It's in an endless loop:
Command-line: C:\MinGW\bin\gdb.exe -nx -fullname -args wxwidgets.exe
Working dir : C:\Documents and Settings\coke.COKE-31670BAFF9\Desktop\New Folder (2)\1\
> set prompt (gdb)
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(no debugging symbols found)
(gdb) (gdb)
> set confirm off
(gdb)
> set width 0
(gdb)
> set height 0
(gdb)
> set breakpoint pending on
(gdb)
> set print asm-demangle on
(gdb)
> set disassembly-flavor intel
(gdb)
> directory C:/DOCUME~1/COKE~1.COK/Desktop/NEWFOL~2/1/
(gdb)
> delete
(gdb)
> run
DBG_CONTINUE);
ContinueDebug
Event (cpid=3548, ctid=1868, DBG_CONTINUE);
ON_DEBUG_EVENT)
id=3548 tid=1868 code=EXCEPTION_DEBUG_EVENT)
NUE);
EVENT)
id=1868 code=EXCEPTION_DEBUG_EVENT)
gdb
: kernel event for pid=3548 tid=1868 code=EXCEPTION_DEBUG_EVENT)
ctid=1868, DBG_CONTINUE);
Co
ntinueDebugEvent (cpid=3548, ctid=1868, DBG_CONTINUE);
ode=EXCEPTION_DEBUG_EVENT)
event for pid=3548 tid=1868 code=EXCEPTION_DEBUG_EVENT)
, DBG_CONTINUE);
ContinueDeb
ugEvent (cpid=3548, ctid=1868, DBG_CONTINUE);
TION_DEBUG_EVENT)
pid=3548 tid=1868 code=EXCEPTION_DEBUG_EVENT)
TINUE);
cpid=3548, ctid=1868, DBG_CONTINUE);
G_EVENT)
tid=1868 code=EXCEPTION_DEBUG_EVENT)
g
db: kernel event for pid=3548 tid=1868 code=EXCEPTION_DEBUG_EVENT)
, ctid=1868, DBG_CONTINUE);
code=EXCEPTION_DEBUG_EVENT)
l event for pid=3548 tid=1868 code=EXCEPTION_DEBUG_EVENT)
68, DBG_CONTINUE);
...(forever until I kill gdb.exe)...
1. delete default.conf
2. select gcc as default compiler again, turn off tips on startup
3. settings->debugger->enable display debugger log
4. close cb
5. open cb
6. no problems yet
7. close cb
8. open cb
9. not problems yet (??? odd)
10. close cb
11. open cb = unhandled exception
12. open cb = unhandled exception
...
If I leave the unhandled exception dialog box open long enough, dr mingw pops up, but only gives:
codeblocks.exe caused an Access Violation at location 60538f8e in module codeblocks.dll Reading from location 00000308.
Registers:
eax=01441870 ebx=013c8850 ecx=00000001 edx=00000308 esi=004a5030 edi=0022f150
eip=00000000 esp=0022fff8 ebp=00000000 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
Call stack:
00000000
Jumped the gun, finally it produced a .rpt:
-------------------
Error occured on Thursday, December 15, 2005 at 21:21:13.
C:\1\src\devel\codeblocks.exe caused an Access Violation at location 60538f8e in module C:\1\src\devel\codeblocks.dll Reading from location 00000308.
Registers:
eax=01441870 ebx=013c8850 ecx=00000001 edx=00000308 esi=004a5030 edi=0022f150
eip=60538f8e esp=0022ef50 ebp=0022ef68 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
Call stack:
60538F8E C:\1\src\devel\codeblocks.dll:60538F8E EditorManager::GetActiveEditor() C:/1/src/sdk/editormanager.cpp:628
00459D87 C:\1\src\devel\codeblocks.exe:00459D87
00406EF3 C:\1\src\devel\codeblocks.exe:00406EF3 CodeBlocksApp::OnAppActivate(wxActivateEvent&) C:/1/src/src/app.cpp:734
100AA0E8 C:\1\src\devel\wxmsw26u_gcc_cb.dll:100AA0E8 _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
100AA4AC C:\1\src\devel\wxmsw26u_gcc_cb.dll:100AA4AC _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
100AB489 C:\1\src\devel\wxmsw26u_gcc_cb.dll:100AB489 _ZN12wxEvtHandler12ProcessEventER7wxEvent
1018413C C:\1\src\devel\wxmsw26u_gcc_cb.dll:1018413C _ZN9wxAppBase9SetActiveEbP8wxWindow
1011466E C:\1\src\devel\wxmsw26u_gcc_cb.dll:1011466E _ZN8wxWindow13MSWWindowProcEjjl
101390FA C:\1\src\devel\wxmsw26u_gcc_cb.dll:101390FA _ZN7wxFrame13MSWWindowProcEjjl
1010C750 C:\1\src\devel\wxmsw26u_gcc_cb.dll:1010C750 _Z9wxWndProcP6HWND__jjl@16
77D48709 C:\WINDOWS\system32\USER32.dll:77D48709 GetDC
77D487EB C:\WINDOWS\system32\USER32.dll:77D487EB GetDC
77D4B368 C:\WINDOWS\system32\USER32.dll:77D4B368 DefWindowProcW
77D4B3B4 C:\WINDOWS\system32\USER32.dll:77D4B3B4 DefWindowProcW
7C90EAE3 C:\WINDOWS\system32\ntdll.dll:7C90EAE3 KiUserCallbackDispatcher
77D493DF C:\WINDOWS\system32\USER32.dll:77D493DF PeekMessageW
77D6E92B C:\WINDOWS\system32\USER32.dll:77D6E92B CallMsgFilterW
77D5688A C:\WINDOWS\system32\USER32.dll:77D5688A LoadBitmapA
77D6B7C5 C:\WINDOWS\system32\USER32.dll:77D6B7C5 SoftModalMessageBox
77D6B12B C:\WINDOWS\system32\USER32.dll:77D6B12B MessageBoxIndirectA
77D95FDF C:\WINDOWS\system32\USER32.dll:77D95FDF MessageBoxTimeoutW
77D80574 C:\WINDOWS\system32\USER32.dll:77D80574 MessageBoxExW
77D9615B C:\WINDOWS\system32\USER32.dll:77D9615B MessageBoxW
1005159D C:\1\src\devel\wxmsw26u_gcc_cb.dll:1005159D _Z17wxSafeShowMessageRK8wxStringS1_
004044BC C:\1\src\devel\codeblocks.exe:004044BC CodeBlocksApp::OnInit() C:/1/src/src/app.cpp:408
0045800C C:\1\src\devel\codeblocks.exe:0045800C
100437F9 C:\1\src\devel\wxmsw26u_gcc_cb.dll:100437F9 _Z14wxUninitializev
100B33BA C:\1\src\devel\wxmsw26u_gcc_cb.dll:100B33BA _Z7wxEntryP11HINSTANCE__S0_Pci
0040148A C:\1\src\devel\codeblocks.exe:0040148A WinMain C:/1/src/src/app.cpp:297
004522EA C:\1\src\devel\codeblocks.exe:004522EA
004011E7 C:\1\src\devel\codeblocks.exe:004011E7
00401238 C:\1\src\devel\codeblocks.exe:00401238
7C816D4F C:\WINDOWS\system32\kernel32.dll:7C816D4F RegisterWaitForInputIdle
A default conf file with these lines does not load (gives the exception):
<main_frame>
<layout>
<TOOLBAR_SHOW bool="1" />
<LEFT_BLOCK_SELECTION int="0" />
<BOTTOM_BLOCK_SELECTION int="0" />
<MAXIMIZED bool="1" />
</layout>
<LAYOUT>
<bin crc="0">FQAAAHd4RG9ja2luZy1TdHJlYW0tdjEuMAgAAAA8bGF5b3V0PgIAAAAFAAAAZnJhbWVAAAAAQAAAAMgAAAA2AgAAAAEAAAAACAAAAExlZnRIb3N0AgAAAGQxYAAAAGAAAAAYAwAAlgAAAAABAAAAAAoAAABCb3R0b21Ib3N0BAAAAAcAAABUb3BIb3N0lgAAAAAAAAAAAAAACgAAAEJvdHRvbUhvc3SWAAAAAAAAAAEAAAACAAAAZDEIAAAATGVmdEhvc3TIAAAAAAAAAAEAAAAFAAAAZnJhbWUJAAAAUmlnaHRIb3N0yAAAAAAAAAAAAAAAFgAAAHd4U2xpZGVCYXItU3RyZWFtLXYxLjABAAAAAAgAAAA8bGF5b3V0PgMAAAAEAAAATWFpbgEIAAAAQ29tcGlsZXIBCAAAAERlYnVnZ2VyAQ==</bin>
</LAYOUT>
</main_frame>
Note the crc of 0. If I change that one line to:
<bin crc="2111425552">FQAAAHd4RG9ja2luZy1TdHJlYW0tdjEuMAgAAAA8bGF5b3V0PgIAAAAFAAAAZnJhbWVAAAAAQAAAAMgAAAA2AgAAAAEAAAAACAAAAExlZnRIb3N0AgAAAGQxYAAAAGAAAAAYAwAAlgAAAAABAAAAAAoAAABCb3R0b21Ib3N0BAAAAAcAAABUb3BIb3N0lgAAAAAAAAAAAAAACgAAAEJvdHRvbUhvc3SWAAAAAAAAAAEAAAACAAAAZDEIAAAATGVmdEhvc3TIAAAAAAAAAAEAAAAFAAAAZnJhbWUJAAAAUmlnaHRIb3N0yAAAAAAAAAAAAAAAFgAAAHd4U2xpZGVCYXItU3RyZWFtLXYxLjABAAAAAAgAAAA8bGF5b3V0PgMAAAAEAAAATWFpbgEIAAAAQ29tcGlsZXIBCAAAAERlYnVnZ2VyAQ==</bin>
Which is the value it had previously, then it load up again fine. But on shutdown it again puts a 0 for the crc. This is the only difference that makes it crash vs not. Looks like something wrong with the crc calculation not getting run or...?
It's obvious. Unchecked pointer.
if(!m_pNotebook) return 0;
The odd thing is that it's the line
if (sel == -1)
that dies and triggers the exception (not the line above it):
0x60538f8c <_ZN13EditorManager15GetActiveEditorEv+54>: mov eax,DWORD PTR [ebp+8]
0x60538f8f <_ZN13EditorManager15GetActiveEditorEv+57>: mov eax,DWORD PTR [eax+56]
0x60538f92 <_ZN13EditorManager15GetActiveEditorEv+60>: mov edx,DWORD PTR [eax]
0x60538f94 <_ZN13EditorManager15GetActiveEditorEv+62>: add edx,0x308
0x60538f9a <_ZN13EditorManager15GetActiveEditorEv+68>: mov eax,DWORD PTR [ebp+8]
0x60538f9d <_ZN13EditorManager15GetActiveEditorEv+71>: mov eax,DWORD PTR [eax+56]
0x60538fa0 <_ZN13EditorManager15GetActiveEditorEv+74>: mov DWORD PTR [esp],eax
0x60538fa3 <_ZN13EditorManager15GetActiveEditorEv+77>: mov eax,DWORD PTR [edx]
0x60538fa5 <_ZN13EditorManager15GetActiveEditorEv+79>: call eax
0x60538fa7 <_ZN13EditorManager15GetActiveEditorEv+81>: mov DWORD PTR [ebp-4],eax
0x60538faa <_ZN13EditorManager15GetActiveEditorEv+84>: cmp DWORD PTR [ebp-4],0xffffffff
(gdb) si
gdb: child_resume.SetThreadContext: thread 1432.0xaec
ContinueDebugEvent (cpid=1432, ctid=2796, DBG_CONTINUE);
gdb: kernel event for pid=1432 tid=2796 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0x60538fa5
0x60538fa5 629 if (sel == -1)
(gdb) si
gdb: child_resume.SetThreadContext: thread 1432.0xaec
ContinueDebugEvent (cpid=1432, ctid=2796, DBG_CONTINUE);
gdb: kernel event for pid=1432 tid=2796 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0xfeeefeee
0xfeeefeee in ?? ()
Not sure why it's making a function call (call [eax]) to get sel off the stack...?
right before it crashes:
(gdb)
gdb: child_resume.SetThreadContext: thread 3400.0x144
ContinueDebugEvent (cpid=3400, ctid=324, DBG_CONTINUE);
gdb: kernel event for pid=3400 tid=324 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_SINGLE_STEP at 0x60538fa3
0x60538fa3 629 ;
(gdb) i r
eax 0x17252b8 24269496
ecx 0x1 1
edx 0x211bbf8 34716664
ebx 0x13d4cb8 20794552
esp 0x22eca4 0x22eca4
ebp 0x22ecbc 0x22ecbc
esi 0x4a5030 4870192
edi 0x22eea4 2289316
eip 0x60538fa3 0x60538fa3
eflags 0x202 514
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0
(gdb) p sel
$19 = 2289316
(gdb) p/x
$20 = 0x22eea4
so sel never gets assigned to (it's the same value at the beginning of the function).
m_pNotebook is valid (non null) though:
p m_pNotebook
$25 = (struct wxNotebook *) 0x1725008
p &m_pNotebook->GetSelection()
does crash gdb though....accessing 0x00000000, so something's not right.
hum. just out of curiosity I changed it to:
EditorBase* EditorManager::GetActiveEditor()
{
SANITY_CHECK(0L);
///int sel = m_pNotebook->GetSelection();
int sel;
sel = m_pNotebook->GetSelection();
if (sel == -1)
return 0;
sdk/editormanager.cpp:628
And now it runs flawlessly, no more exception. So 1) is there something about local variable initializers that I don't get...why aren't they equivalent??? and 2) can the code be changed to not use a default initializer and use the old c89 (?) style like above? Seems to fix the problem (but I'd still like to know why).
The wxChar* doesn't compile (it's expecting wxCharBuffer). Anyway the following does:
unsigned long wxCrc32::FromString(const wxString& text)
{
static unsigned long *crc_table = NULL;
unsigned long crc = 0;
///const char* p = text.mb_str(wxConvUTF8);
int i = 0;
///const wxCharBuffer wxcb = text.mb_str(wxConvUTF8);
if (text)
{
// Get the crc table, on first call, generate, otherwise do nothing
crc_table = GetCRC32Table( crc_table ) ;
// Do we have a crc table?
if ( crc_table )
{
// Calculate the checksum
crc = 0xFFFFFFFFUL;
while (text[i])
{ crc = (crc>>8) ^ crc_table[ (crc^(text[i++])) & 0xFF ]; }
crc ^= 0xFFFFFFFFUL ;
}
}
// If we have a crc table, delete it from memory
if ( crc_table ) { delete[] crc_table; }
// Set it to a null pointer, the have it (re)created on next calls to this
// function
crc_table = NULL;
// Return the checksum result
return( crc ) ;
}
But that's not the whole cause. Set a breakpoint (pending bps are $$$ btw) and trace to:
if ( crc_table )
and it crashes. Must be something in the crc table funcion above (and I must admit, I'm not wx unicode expert).
Tracing through this a bit more:
Now I can get it to trace through the crc stuff fine, but it returns and was called from:
src/main:800
buf = Manager::Get()->GetConfigManager(_T("app"))->ReadBinary(_T("/main_frame/layout"));
Now why that triggers a crc calculation, I'm really at a loss:
default.conf:
<main_frame>
<layout>
<TOOLBAR_SHOW bool="1" />
<LEFT_BLOCK_SELECTION int="0" />
<BOTTOM_BLOCK_SELECTION int="0" />
<MAXIMIZED bool="1" />
</layout>
<LAYOUT>
<bin crc="-1075901594">FQAAAHd4RG9ja2luZy1TdHJlYW0tdjEuMAgAAAA8bGF5b3V0PgIAAAAFAAAAZnJhbWVAAAAAQAAAAMgAAAA2AgAAAAEAAAAACAAAAExlZnRIb3N0AgAAAGQxYAAAAGAAAAAYAwAAlgAAAAABAAAAAAoAAABCb3R0b21Ib3N0BAAAAAcAAABUb3BIb3N0lgAAAAAAAAAAAAAACgAAAEJvdHRvbUhvc3SWAAAAAAAAAAEAAAACAAAAZDEIAAAATGVmdEhvc3TIAAAAAAAAAAEAAAAFAAAAZnJhbWUJAAAAUmlnaHRIb3N0yAAAAAAAAAAAAAAAFgAAAHd4U2xpZGVCYXItU3RyZWFtLXYxLjABAAAAAAgAAAA8bGF5b3V0PgMAAAAEAAAATWFpbgEIAAAAQ29tcGlsZXIBCAAAAERlYnVnZ2VyAQ==</bin>
</LAYOUT>
</main_frame>
As you can see, there is <layout> and <LAYOUT>. Now XML should be case-sensitive, so is the xml parser being used broken wrt case?
It now crashed 3 lines lower:
main.cpp:803
pSlideBar->LoadFromStream( ms );
I would check the memory management stuff. Definately looks like heap corruption.
No, w/ memory corruption it can crash anywhere (esp places unrelated).
But the problem seems to be coming from computing a 0 crc and storing that.
sdk/configmanager.cpp:896:
s->SetAttribute("crc", wxCrc32::FromString(source));
This is called when CB shuts down to save the crc info. Tracing this, source = " ". i.e. an empty space, followed by 0x0.
This is the line which calls it:
main.cpp:837 in MainFrame::SaveWindowState
wxMemoryOutputStream os;
pLayoutManager->SaveToStream( os );
pSlideBar->SaveToStream( os );
wxString buf(static_cast<const wxChar*>(os.GetOutputStreamBuffer()->GetBufferStart()), os.GetSize());
Manager::Get()->GetConfigManager(_T("app"))->WriteBinary(_T("/main_frame/layout"), buf); <-------
That casting scares me. Not sure how:
<TOOLBAR_SHOW bool="1" />
<LEFT_BLOCK_SELECTION int="0" />
<BOTTOM_BLOCK_SELECTION int="0" />
<MAXIMIZED bool="1" />
gets converted to a " " buffer?
The other thing was that the crc returns a long int, but the xml output routine takes in an int. So we get a negative # in the default.conf file, maybe that's also an issue...
ahh... uncheck return value:
main.cpp:800 (LoadWindowState())
buf = Manager::Get()->GetConfigManager(_T("app"))->ReadBinary(_T("/main_frame/layout")); <-------
wxMemoryInputStream ms(buf.c_str(), buf.Length());
pLayoutManager->LoadFromStream( ms );
pSlideBar->LoadFromStream( ms );
and configmanager.cpp:920
if(bin->QueryIntAttribute("crc", (int*)&crc) != TIXML_SUCCESS)
return wxEmptyString;
So in main.cpp, buf gets set to the wxEmptyString returned by ReadBinary(), and then we don't guard the
wxMemoryInputStream ms(buf.c_str(), buf.Length());
pLayoutManager->LoadFromStream( ms );
pSlideBar->LoadFromStream( ms );
code for the case when buf == wxEmptystring.
Tracing further, the calced and stored crcs DO match. This is not the problem. The problem lies in
sdk\base64.cpp:wxBase64::Decode()
it takes a wxString (and not a buffer??? isn't this wrong since a 0 is valid in a byte buffer but not in a string....) and returns a wxString.
Set a breakpoint in the function. You will see it correctly gets passed the <bin></bin> text value:
FQAAAHd4RG9ja2luZy1TdHJlYW...
However the base64 decode algorithm builds up a return string starting with ' ', followed by 0x0, etc. This is not OK for a string value. i.e. The returned string is 0x15,0x0, "wxDocking-Stream-v1.0"
See:
http://chxo.com/scripts/base64.php
To decode the string yourself and then click view source on your web browser....you'll see it starts off with binary non-string values.
[attachment deleted by admin]
Well, even if 0x0 nulls are OK in wxStrings, when we build a memory stream from the c_string version of the wxString, doesn't this chop off at the first 0x0?
buf = Manager::Get()->GetConfigManager(_T("app"))->ReadBinary(_T("/main_frame/layout"));
wxMemoryInputStream ms(buf.c_str(), buf.Length());
And then the ms memorystream wouldn't hold all it should, so it crashes a few lines below.
Edit:
When I put a watch on ms after those two lines, gdb gives <incomplete type>. Tracing into the wxSlideBar::LoadFromStream -> wxUtil::ReadString() call,
wxDockit/src/generic/util.cpp:34
stream.Read( &size, sizeof( size ) );
sets size to 1392520448. We then allocate a buffer:
char* psz = new char[size + 1];
whoops.
Well, even if 0x0 nulls are OK in wxStrings, when we build a memory stream from the c_string version of the wxString, doesn't this chop off at the first 0x0?
No. wxMemoryInputStream comes in two flavours.
wxMemoryInputStream ms(buf.c_str(), buf.Length());
^^^^^^^^^^^^
This one is safe to be used with 0x0, the other is not.
I don't understand this, in wx/mstream.h the ctor is defined as
wxMemoryInputStream(const void *data, size_t length);
wxMemoryInputStream(const char *data, size_t length);
unsigned long wxCrc32::FromString(const wxString& text)
{
static unsigned long *crc_table = NULL;
unsigned long crc = 0;
const char* p = text.mb_str(wxConvUTF8);
if (text)
{
// Get the crc table, on first call, generate, otherwise do nothing
crc_table = GetCRC32Table( crc_table ) ;
// Do we have a crc table?
if ( crc_table )
{
// Calculate the checksum
crc = 0xFFFFFFFFUL;
while (*p)
{ crc = (crc>>8) ^ crc_table[ (crc^(*p++)) & 0xFF ]; }
crc ^= 0xFFFFFFFFUL ;
}
}
// If we have a crc table, delete it from memory
if ( crc_table ) { delete[] crc_table; }
// Set it to a null pointer, the have it (re)created on next calls to this
// function
crc_table = NULL;
// Return the checksum result
return( crc ) ;
}
This computes the correct crc (verified same as 1512 binary):
unsigned long wxCrc32::FromString(const wxString& text)
{
static unsigned long *crc_table = NULL;
unsigned long crc = 0;
int i = 0;
if (text)
{
// Get the crc table, on first call, generate, otherwise do nothing
crc_table = GetCRC32Table( crc_table ) ;
// Do we have a crc table?
if ( crc_table )
{
// Calculate the checksum
crc = 0xFFFFFFFFUL;
while (text[i])
{ crc = (crc>>8) ^ crc_table[ (crc^(text[i++])) & 0xFF ]; }
crc ^= 0xFFFFFFFFUL ;
}
}
// If we have a crc table, delete it from memory
if ( crc_table ) { delete[] crc_table; }
// Set it to a null pointer, the have it (re)created on next calls to this
// function
crc_table = NULL;
// Return the checksum result
return( crc ) ;
}
Should the latter be used? I think it's something about the conversion in unicode or ???
crc is a binary data check, I have no idea why it's taking variable length srings at all. It should take a void* and size_t and cast it to unsigned char :?
unsigned int wxCrc32::FromString(const wxString& text)
{
const char* p = text.mb_str(wxConvUTF8);
return FromBytes(p, strlen(p));
}
unsigned int wxCrc32::FromBytes(const void* data, size_t length)
{
static unsigned int *crc_table = NULL;
unsigned int crc = 0;
const unsigned char* p = static_cast<const unsigned char*>(data);
if (p)
{
// Get the crc table, on first call, generate, otherwise do nothing
crc_table = GetCRC32Table( crc_table );
// Do we have a crc table?
if ( crc_table )
{
// Calculate the checksum
crc = 0xFFFFFFFFUL;
while (length--)
{ crc = (crc>>8) ^ crc_table[ (crc^(*p++)) & 0xFF ]; }
crc ^= 0xFFFFFFFFUL ;
}
}
// If we have a crc table, delete it from memory
if ( crc_table ) { delete[] crc_table; }
// Set it to a null pointer, the have it (re)created on next calls to this
// function
crc_table = NULL;
// Return the checksum result
return( crc ) ;
}
Building a clean ansi build to test on but it should work. There may be another unicode bug re syntax highlighting but it looks like a seperate issue. Have to look at a couple of different revisions (both ansi & unicode) to isolate it: basically open a .cpp, click settings->editor->OK. do that twice in a row and the syntax highlighting dissapears - 280Z28 pointed it out and I haven't got a chance to look at it further but right now: 1512 ansi doesn't exhibit, 1537 unicode does (but this should be a seperate thread anyway).
Also, since people have said they couldn't get unicode to build for whatever reasons, here's all the relevant settings that should be checked (they assume a WX_SFX custom variable that should be blank for ansi and u for unicode, just to be appended to msw$(WX_SFX) to make switching back and forth easier (present in the unicode.patch)) :
0 compile either an ansi (UNICODE=0) or unicode (UNICODE=1) build - at the cmd.exe prompt
type:
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb
(if you get an error then update to a later mingw (make >= 3.80 needed))
1 checkout svn source with tortoisesvn.
2 right click checked out directory and apply patch - apply unicode.patch - right-click on
file list -> patch all (this won't be necessary once the unknown exception bug fix is in svn)
3 open CodeBlocks-NewBuild.cbp with a recent codeblocks build (download one of the svn
binaries you can find links to in the forums)
4 goto project -> build options
5
ANSI
====
Compiler->#defines
make sure wxUSE_UNICODE if present is:
wxUSE_UNICODE=0
Custom variables
WX_CFG=NonUnicode
WX_SFX=
rename wxWidgets-2.6.2\lib\gcc_dll to wxWidgets-2.6.2\lib\gcc_dllNonUnicode
open wxWidgets-2.6.2\lib\gcc_dllNonUnicode\msw\wx\setup.h
it should have
#define wxUSE_UNICODE 0
UNICODE
=======
Compiler->#defines
make sure wxUSE_UNICODE if present is:
wxUSE_UNICODE=1
Custom variables
WX_CFG=NonUnicode
WX_SFX=u
rename wxWidgets-2.6.2\lib\gcc_dll to wxWidgets-2.6.2\lib\gcc_dllUnicode
open wxWidgets-2.6.2\lib\gcc_dllUnicode\msw\wx\setup.h
it should have
#define wxUSE_UNICODE 1
6 save the project and exit CodeBlocks. This is necessary so the custom variables get set
and reloaded.
7 hit compile and if it prompts you to set the wx variable, just browse to the
wxWidgets-2.6.2 directory and hit ok
8 let it compile and run update.bat once it finishes
Those should be the only settings that affect ansi vs. unicode building.
Update: OK tested and the patch works on ansi as well. Looked over all the diffs and everything looks clean. It's a merge of thomas' main.patch.txt and changes made by 280Z28. I'll post the link to the file for now:
280Z28: if you have a more recent version or whatever I'll take the link down, but wanted to have something people could look over now as it tests and looks fine for clean checkouts of both unicode and ansi builds.
http://www.geocities.com/grv575/unicode.zip
Finally, the syntax highlighting thing looks like a unicode only thing - doesn't show up in ansi builds but does in unicode (both with and without the unicode.zip patch so it's a seperate issue). A third seperate <snip...lies about some nonexistant behavior deleted>