Compiled latest svn, set debugger settings to show debugger log, closed cb, started it again and I get the unknown exception dialog every time. Went away after I opened CB revision 1512 (binary downloaded) to reset the cb settings. Closed rev 1512, reopened latest svn cb and it starts this time. Don't know exactly what threw the exception...
You compiled it with unicode support?
http://forums.next.codeblocks.org/index.php?topic=1618.0
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).
Ok, had nothing to do with the exe still running (was a gdb session that didn't terminate cleanly).
But what's odd is that I get the unknown exception every time I launch the svn version.
Then if I open the 1512 version, close that, and then open the svn version it opens fine. But once I close it (thus letting it save settings) it will not reopen again. So is it saving some setting that it can't read properly?
Quote from: grv575 on December 16, 2005, 02:49:31 AM
Ok, had nothing to do with the exe still running (was a gdb session that didn't terminate cleanly).
But what's odd is that I get the unknown exception every time I launch the svn version.
Then if I open the 1512 version, close that, and then open the svn version it opens fine. But once I close it (thus letting it save settings) it will not reopen again. So is it saving some setting that it can't read properly?
If you read my thread I was having trouble where once it created the default.conf file it would crash. It sounds like you're having the same thing happen.
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)...
The unknown exception problem definately has something to do with the codeblocks default.conf parsing. It's very repeatable:
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
Haha that's the same place (function) mine was crashing, only mine didn't give a line number I don't think!
OK traced the bug by comparing default.conf files at various stages.
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;
Adding that (editormanager.cpp:628) null check doesn't stop it from going off!
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.
How did you get it to load in the debugger??
I keep getting this :x :x
http://forums.next.codeblocks.org/index.php?topic=1653.0
Only this time it's not with bf2.cpp, it's with the Code::Blocks files.
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).
They are equivalent. You have a buffer overflow corrupting your memory somewhere and that line changed the code enough that you aren't seeing it... for now. But it's still there.
Yeah, I just changed it back and forth, and now it compiles to the same code...so no idea
I'm working on it but... not getting anywhere. :?
Ok I got it to compile in Unicode. My dear....
Now, I wonder if I fixed that bug... probably not. :o
OK I fixed this.
All that's left now is getting a Unicode enabled XML library. I can convert TinyXML, but is there something faster?
It's a pretty easy conversion really.
Maybe not necessary any more (rewriting TiX).
Regarding the CRC calculation (which is definitely the reason for the exception), I am rather sure it will work if const char* is replaced by const wxChar* in crc32.cpp, line 96.
That's because wxCharBuffer uses wchar in Unicode, so the pointer arithmetic inside the CRC calculation is not good.
However, I have no way to test it because Code::Blocks wx-Unicode won't link on my machine.
I have modified crc32.cpp in HEAD accordingly even though I can't test if that fixes the bug.
It is not worse in any case, and if that was the cause, the problem is fixed now :)
Quote from: thomas on December 16, 2005, 01:54:14 PM
I have modified crc32.cpp in HEAD accordingly even though I can't test if that fixes the bug.
It is not worse in any case, and if that was the cause, the problem is fixed now :)
I fixed that error already, and not like that. That wasn't the problem...... I can send a patch once the dialog positioning code is checked in??
Edit: Where did I post my patch? I can't find it loolll!! Maybe it's still just here on my desktop. :x
Edit: It's in my final post in the thread about it. I am sorry. :( Should I add it to SourceForge too since I already posted it, but not in the right place?
Quote from: 280Z28 on December 16, 2005, 03:39:13 PM
Should I add it to SourceForge too since I already posted it, but not in the right place?
Yes! VERY YES!
Quote from: rickg22 on December 16, 2005, 05:16:16 PM
Quote from: 280Z28 on December 16, 2005, 03:39:13 PM
Should I add it to SourceForge too since I already posted it, but not in the right place?
Yes! VERY YES!
Already done a while ago :) Hopefully I remember in the future :oops:
Why do you keep telling that... I have been looking both under "bugs" and under "patches". It is not there.
Quote from: thomas on December 16, 2005, 05:28:42 PM
Why do you keep telling that... I have been looking both under "bugs" and under "patches". It is not there.
Ohhhhh I was talking about the positioning patch. It's the only one I've submitted because it's going to very hard to isolate the others while the diff shows 50 files were changed. I'm waiting for that one and then I have 5 or so more patches in a row
I'll put of SF. ;)
Well you know... bluntly speaking, the positioning patch is really not important. Those are cosmetics.
Grv575 cannot use Code::Blocks because of the bug in the CRC calculation - this is a showstopper.
It effectively prevents him from using Code::Blocks alltogether (and not him alone, many people who use Unicode).
So if you have really solved that problem, then it would maybe a good idea if you made this patch a number 1 priority. Or you could at least describe what is wrong, then we can patch it by hand. You know, reading "I have fixed it long ago" over and over is quite annoying if it does not work for you personally... put yourself into that position.
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).
I am not getting Code::Blocks to link with Unicode. It does not find various XRC related stuff :(
So I cannot work on this, sorry.
Quote from: thomas on December 16, 2005, 06:14:59 PM
Well you know... bluntly speaking, the positioning patch is really not important. Those are cosmetics.
Grv575 cannot use Code::Blocks because of the bug in the CRC calculation - this is a showstopper.
It effectively prevents him from using Code::Blocks alltogether (and not him alone, many people who use Unicode).
So if you have really solved that problem, then it would maybe a good idea if you made this patch a number 1 priority. Or you could at least describe what is wrong, then we can patch it by hand. You know, reading "I have fixed it long ago" over and over is quite annoying if it does not work for you personally... put yourself into that position.
Please, all I ask is you patch the one single patch I posted already so I can get a diff of this one. :( I'm not trying to be a ***** about it. Seriously, it's just that there are a lot of files that show up in "svn status" and then I have to do a diff on every single one to find the interspersed other patches. With the dialog patch committed, "svn status" will return a much smaller number of files and I'll be able to easily post patches for the other issues. I posted another patch just now actually... a 2-liner. I'm at work and don't have my SF password so it says I'm a nobody lol. It's the auto-complete spacing patch on SF. But yes the one I'm stuck on for svn status is the dialog one.
280: Just submit the showstopper patch... we don't mind how old it is, we can work around that. Just submit it please.
Quote from: 280Z28 on December 16, 2005, 06:26:06 PM
Quote from: thomas on December 16, 2005, 06:14:59 PM
Well you know... bluntly speaking, the positioning patch is really not important. Those are cosmetics.
Grv575 cannot use Code::Blocks because of the bug in the CRC calculation - this is a showstopper.
It effectively prevents him from using Code::Blocks alltogether (and not him alone, many people who use Unicode).
So if you have really solved that problem, then it would maybe a good idea if you made this patch a number 1 priority. Or you could at least describe what is wrong, then we can patch it by hand. You know, reading "I have fixed it long ago" over and over is quite annoying if it does not work for you personally... put yourself into that position.
Please, all I ask is you patch the one single patch I posted already so I can get a diff of this one. :( I'm not trying to be a ***** about it. Seriously, it's just that there are a lot of files that show up in "svn status" and then I have to do a diff on every single one to find the interspersed other patches. With the dialog patch committed, "svn status" will return a much smaller number of files and I'll be able to easily post patches for the other issues. I posted another patch just now actually... a 2-liner. I'm at work and don't have my SF password so it says I'm a nobody lol. It's the auto-complete spacing patch on SF. But yes the one I'm stuck on for svn status is the dialog one.
Sam, let's get some things straight here.
We appreciate
every contribution from the community but what is accepted and what is not
is not for you to decide. For many good reasons.
As you 've probably understood by now (since you 're very active on these forums), the HEAD version is undergoing some heavy face lifting. This means we 're progressing with a plan on what to do next. Some patches, especially trivial ones, might be postponed for later.
The things that
you find important are
not necessarily important for everyone else, and vice-versa.
For me it's more important to fix the crash grv575 is experiencing or the "only-prints-first-page" bug. You know, I went shopping for a new printer today
just to fix this bug, as my old printer was broken for some time now.
So to make it short: your priorities are
not our priorities and you have to respect that.
Don't get me wrong. I, and everyone else, appreciate the work you 're putting into the project but you should align this work more closely with what's needed now. By saying "
apply this patch now and then I will post more", where "more" are more important patches is plain wrong.
Yiannis.
Thanks rickg22 for commenting on what I submitted. I should tell y'all, if I'm waiting on something, feel free to say you aren't going to submit it if you really won't. If you say so, I won't waste yours and my time going on about it. I made a mistake before and just now corrected it on the sourceforge page.
I wish y'all would have made a direct comment about the other patch earlier. I thought it would be submitted early this morning and no one would be waiting. Let me know if that one will be committed soon. If so, I'll wait a few minutes, svn update, and then submit other patches. If you aren't going to commit it, say so, and I'll revert my local copy (there's already a backup of the patch) and then merge back only the other changes. That'll take me a bit more time, but less time than waiting forever and never posting. :)
I would never hold code hostage. All I was doing was waiting for an answer. I'm sorry we've had so many misunderstandings. :cry: I think things will feel more cooperative once I get a better idea of what y'all are looking for. I am new, that is for sure, and when I get confused I say things that are easily taken to be mean or rude when I don't mean them to be. :(
After having just gotten back from working on a 3 person large coding assignment, I somehow got the job of integrating all the seperate parts we worked on seperately. The biggest annoyance was then, after merging everything and spending hours to get things to compile, people would still not update to the latest tree and work on that...they'd submit me mods based on very old working copies - which is really unmanageable.
Honestly, if I can add my 2 cents, the most important thing for a large collaborative project is to always check out the latest copy, make changes, and then make sure the code changes you commit are relative to the latest svn/cvs code. If you are going to work on > 1 patch at once, then make a .diff file, store that away somewhere, and you can always later apply it against whatever revision it was done against, and then merge those changes with current. Plus that's not always necessary since you have 4 lines of context code, and patches ususally aren't too involved...
But, working with your own working copy constantly really isn't appropriate for a multi-user versioned project.
Sam,
I think it is most easiest to revert your copies back, and have the multiple monitor bug (some don't consider this a bug, I do consider it, since it is very annoying if your head is going from left to right like watching a live tennis game) fix at a later stage. Don't get me wrong, I would like to see your patch for the multiple monitors in rather today then tomorrow, but as Yiannis said this is not up to us to decide.
I know it is a little bit frustrating that fixes which are ready are not inserted into head immediately (I have for example also made some fixes some weeks ago, and those are also not yet in head), but I know someday they will get in there well I hope). Off course I know keep track on the files that I have changed and that are being changed in head, so I can re-apply the fix on newer revisions, that's an anoying thing to do, I admit. But for us this is just a little pile of work, but for the CB developers it is a huge pile of work, since they get patches, new features from everywhere and most importantly they are in the middle of a big change of the sdk, which they want to get out of the door asap. And that is also another thing I want to happen asap, that changed sdk (could probably cause us to rsynch our fixes on changed files).
What I can tell from your posts is that you found several bugs and fixed them, which I think is very good, and as a user, plug-in developer, bug fixer for CB I am very thankfull for that, and I hope you will be able to fix much more bugs, aswell as I hop to fix much more bugs. I want to see the number of bugs at sf go down down down.
I hope that all of use will be able to fix much more bugs, add much more functionality, and hopefully the core devs will be abl to quickly catch up on them.
Let's hope the team also grows, then maybe there can be some patch reviewer person or something like that.
Nevertheless, I think all will sort out fo the best.
So let's kick ass and create a wonderfull project, but as for us little helpers always listen to the boss ... 8)
Cheers,
Lieven
Sam: I got an idea. Keep your positioning-version (including sources) in a directory, let's call it "codeblocks-custom". And use that copy to debug others.
Then bear with the existing bugs as you try to update / compile etc. Now, I think I speak for all of us devs when I say that the positioning bug will NOT be fixed until later. We'll work first on the CRC showstopper bug.
So after you've kept a backup and made a diff on all your files, update with the latest SVN. Thank you.
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.
http://wxextended.sourceforge.net/docs/slidebar_8cpp-source.html <- here's the sourcecode for wxExtended's slidebar.cpp. Is that it?
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.
I see. So we have 2 tasks:
1) Take into account the "zero" CRC special case (it CAN happen, you know). Can you do this, grv?
2) Fix the bug that makes the CRC get miscalculated in the first place. <- This is going to get tricky.
Quote from: grv575 on December 16, 2005, 08:09:16 PM...
Grv575, the problem is that LoadWindowState does not check the return value it gets from ConfigManager.
The CRC is calculated over the binary layout data which is saved. This is actually meant to
prevent crashes (yes I know, that's ironic). The background of this is that people are editing the config file in a text editor. I don't like it, but there's nothing you can do against that. The CRC is meant to prevent accidential changes to binary data (which will be detrimental in most cases and very hard to see).
So when ConfigManger saves and restores binary data, it calculates the CRC, and if the checksum does not match, it returns wxEmptyString. Now there are two problems:
1. the CRC is not correct due to some bug which only happens in Unicode
2. LoadWindowState does not care and just hands wxEmptyString over to wxDockit.
Solution: the CRC calculation must be fixed (and, there should be a check against wxEmptyString). Unluckily, I do not know what is wrong in the CRC calculation.
About the xml tags... No, the parser is not broken. You are right, LAYOUT and layout are two completely different things, this is intentional :)
Quote from: rickg22 on December 16, 2005, 08:47:28 PM1) Take into account the "zero" CRC special case (it CAN happen, you know). Can you do this, grv?
No...! CRC == 0 is perfectly valid.
What ConfigManager does is it compares the
stored CRC with the
freshly calculated one. These two must be the same, whether they are zero or any other number does not matter. They just have to be correct :)
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]
There is no
0x00 in a bin64 encoded string :) Luckily, or we couldn't do that :)
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+ <--- these are all.
Quote from: grv575 on December 16, 2005, 09:23:08 PMHowever 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"
Right, but the data
really looks like this. This is correct. And wxString is meant to hold
0x00 values. This certainly works.
See message one up. I just upped the screenshot. I'm not sure how that <bin></bin> string got calculated, but it looks incorrect in Unicode mode. The first two boxes in the screenshot are 0x15,0x0. These should all be spaces I would think.
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.
Quote from: grv575 on December 16, 2005, 09:32:41 PM
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.
Look at the screenshot. Specifically the size variable value after reading the stream. Also at where the gdb -> arrow is. I trace one more line, (allocate that huge char buffer) and it gives the exception. See it's heap corruption after all. Malloc() == :)
Something wrong with the stream encode or decode or... at least with a unicode build.
[attachment deleted by admin]
no idea if this might give any hints or not, but tiwag and I suffered also from a problem tht our debug toolbar was gone. The only way to get it back was deleting the <LAYOUT> ... crc ... thingy. This was on a windows NON unicode build.
Hope this is usefull information.
Oh Yes!! And I think I know what is wrong. Look:
http://www.wxwidgets.org/manuals/2.6.2/wx_wxmeminputstream.html#wxmemoryinputstreamctor
It takes len chars, but wxString has len wchars in Unicode!
So we have to... umm... do without a wxString outside wxDockit. The base64 data is byte data, by definition. But... if we put it into a wxString, it is transformed to double-byte nevertheless. It does not matter normally, but here it does, because wxMemoryInputStream apparently does not understand Unicode...
So we have to allocate a char[] and copy the characters from the string in there.... or rewrite both Base64Decode and ConfigManager. I guess copying the characters to a char[] will be easier.
I don't understand this, in wx/mstream.h the ctor is defined as
wxMemoryInputStream(const void *data, size_t length);
and not as
wxMemoryInputStream(const char *data, size_t length);
If this builds, I have a patch for you. What. A.Pain. That. Was. :shock:
All the other patches I already posted on SF.
I keep switching between unicode and non to make sure both are working... not just one.
Quote from: Takeshi Miya on December 17, 2005, 01:35:25 AM
I don't understand this, in wx/mstream.h the ctor is defined as
wxMemoryInputStream(const void *data, size_t length);
and not as
wxMemoryInputStream(const char *data, size_t length);
No...?
Quote from: http://www.wxwidgets.org/manuals/2.6.2/wx_wxmeminputstream.html#wxmeminputstreamwxMemoryInputStream::wxMemoryInputStream
wxMemoryInputStream(const char * data, size_t len)
Apart from that,
sizeof(void) == sizeof(char) so it would not matter anyway.
Try if this works in Unicode, please. It might just do fine (it works in ANSI, and it is a lot easier).
[attachment deleted by admin]
Quote from: thomas on December 17, 2005, 02:09:59 AM
Try if this works in Unicode, please. It might just do fine (it works in ANSI, and it is a lot easier).
It's building :)
It'll work if you change everything in appglobals.h back to #define statements
[attachment deleted by admin]
No, I'll rather change the about box... but that can wait until tomorrow morning.
The important thing is whether this patch fixes the crash. Because if it does, then we can stop looking now, and I'll commit it after sleeping for 5 hours...
Quote from: thomas on December 17, 2005, 02:46:10 AM
No, I'll rather change the about box... but that can wait until tomorrow morning.
The important thing is whether this patch fixes the crash. Because if it does, then we can stop looking now, and I'll commit it after sleeping for 5 hours...
The about box.. the title bar.. the status bar..
It wasn't crashing on me
Oh yeah, you have to change wxChar* back to char* in wxCrc32::FromString()
That's all I had to do to 1536+your patch to make it build.
Perfect. works. build 1524 tested. Do note that the generated default.conf file will crash prior versions now :)
But just make a note of it in the wiki - delete default.conf if you get an undefined exception.
One thing. This gives a crc of 0:
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 ) ;
}
I set those back to #defines in appglobals.h, and made the change above to the crc check, and now it saves the CRC and looks like this. :)
[attachment deleted by admin]
I tested 280Z28's unicode.patch under a unicode build and it fixes the problem as well as uses an unsigned int for the crc as it should (the xml routines accept and int and overflow giving a negative crc if it gets an unsigned long - this was one of the problems it seems).
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>
We aren't new to the highlighting bug.
http://sourceforge.net/tracker/index.php?func=detail&aid=1372906&group_id=126998&atid=707416
Oh, you are around. Do you mind if I post the unicode patch? It looks good (see modified post above)
Quote from: grv575 on December 17, 2005, 08:16:41 AM
Oh, you are around. Do you mind if I post the unicode patch? It looks good (see modified post above)
Sure, but I didn't post it because people were complaining about the preprocessor directives. I tryed 3 different ways of using wxString but in the end I went with something that's time-proven reliable.
You don't have to rehost it btw, I own the server it's on. ;)
I have other stuff done, but you can find it in the top 8 latest patches on SF (I was a nobody from work :cry: ).
OK, not aware of that discussion, but I figure that those changes can just be ignored if not desired. At least the patch for this crash is ready to be integrated into the tree once devs have verified.
Quote from: grv575 on December 17, 2005, 08:21:23 AM
OK, not aware of that discussion, but I figure that those changes can just be ignored if not desired. At least the patch for this crash is ready to be integrated into the tree once devs have verified.
I say go back to the directives. Variables didn't work once, there's a patch ready that does work with directives, why spend any more time on it? :)
You want to be the one to put it on SF? haha :lol:
Edit: For what I was talking about, see replies 57, 58 in this thread.
I have committed my patch to main.cpp along with grv575's modification to crc32.cpp.
I don't like mangling FromString() through FromBytes(), as it introduces unnecessary indirection and works on char pointers instead of using safe string ops.
Replacing long by int in the crc table does not make anything better. These are logically different types, but exactly the same on all modern architectures. And on older architectures, int would acutally break that particular code.
It means rewriting the whole function and the functions calling it with no noticeable difference (identical executable).
Besides, it is tinyXML which uses signed variables and introduces the minus sign in the xml, consequentially. There is nothing we can do about that short of either rewriting tinyXML or converting the CRC to a string. Neither solution is required or advisable, though.
The changes regarding reverting appglobals.h to using macros are also not committed because that makes no sense at all. Yiannis changed the #defines to const wxStrings to get rid of some macros.
If there is a problem in some code using the constants (about box, for example), then that code should be adjusted.
Quote from: thomas on December 17, 2005, 02:44:42 PM
I have committed my patch to main.cpp along with grv575's modification to crc32.cpp.
I don't like mangling FromString() through FromBytes(), as it introduces unnecessary indirection and works on char pointers instead of using safe string ops.
Replacing long by int in the crc table does not make anything better. These are logically different types, but exactly the same on all modern architectures. And on older architectures, int would acutally break that particular code.
It means rewriting the whole function and the functions calling it with no noticeable difference (identical executable).
Besides, it is tinyXML which uses signed variables and introduces the minus sign in the xml, consequentially. There is nothing we can do about that short of either rewriting tinyXML or converting the CRC to a string. Neither solution is required or advisable, though.
The changes regarding reverting appglobals.h to using macros are also not committed because that makes no sense at all. Yiannis changed the #defines to const wxStrings to get rid of some macros.
If there is a problem in some code using the constants (about box, for example), then that code should be adjusted.
Long and int are different on 64bit platforms, and as such broke one of our math libraries. :( If you know it's a 32bit answer you want, you need to use int. long is 64bits on 64bit platforms.
My two Athlon64 PCs and my Turion64 notebook don't seem to know that.
Anyway, that can be adressed at a later time separately.
Quote from: thomas on December 17, 2005, 02:44:42 PM
Besides, it is tinyXML which uses signed variables and introduces the minus sign in the xml, consequentially. There is nothing we can do about that short of either rewriting tinyXML or converting the CRC to a string. Neither solution is required or advisable, though.
Why
not convert it to a string? There shouldn't be a performance disadvantage as tinyXML would otherwise do that anyway, right? So what's the problem with moving that conversion to C::B itself where you know the CRC is unsigned and will handle it properly?
Because it does not matter, -923485 and 4294043811 is the same binary number, the computer knows no difference.
You would only know if you looked at the XML file in a text editor, and reading the CRC does not tell you much anyway (except if you are that autistic boy from The Mercury Project).
So, is it fixed or not? (Just wondering)
Yes :)
Checked out 1541 and tested both unicode and ansi builds. CRC calculation is correct and the crash is fixed.
Quote from: thomas on December 17, 2005, 02:53:14 PM
My two Athlon64 PCs and my Turion64 notebook don't seem to know that.
Anyway, that can be adressed at a later time separately.
CPU: Athlon 64OS: 32 bitslong=32 bits
int=32 bits
OS: 64 bitslong=64 bits
int=32 bits
As long as it overflows consistently then the crcs should still match (haven't double-checked but I think this is the case as a negative crc was matching over here so this must mean it casts to int first before it compares)
Quote from: grv575 on December 17, 2005, 08:10:00 PM
Checked out 1541 and tested both unicode and ansi builds. CRC calculation is correct and the crash is fixed.
CRC calculation, while non-zero, is not correct, but whatever. As long as it returns a unique number for an input it's fine?
I fixed the syntax highlighting bug. Put yet another patch on SF...
Edit: I hate sf... I get this at least once a night when I'm trying to post something, plus it won't remember that I want my login remembered (across browser restarts)!!
QuoteWe're Sorry.
The SourceForge.net Website is currently down for maintenance.
We will be back shortly
It is using wxUInt32 now, that is as much cross-platform-32bits as we can get.
Quote from: thomas on December 18, 2005, 03:21:05 PM
It is using wxUInt32 now, that is as much cross-platform-32bits as we can get.
Yep, that's the one :)