Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: grv575 on December 16, 2005, 02:35:25 am

Title: unknown exception
Post by: grv575 on December 16, 2005, 02:35:25 am
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...
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 02:40:38 am
You compiled it with unicode support?

http://forums.codeblocks.org/index.php?topic=1618.0
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 02:41:44 am
Actually, it comes up whenever I'm clicking on a wxSmith.cbp project now.  Maybe it has something to do with:

Code: [Select]
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).
Title: Re: unknown exception
Post by: 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?
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 02:54:22 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.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 03:09:55 am
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:

Code: [Select]
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)...
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 03:22:39 am
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:

Code: [Select]
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:

Code: [Select]
-------------------

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
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 03:39:04 am
Haha that's the same place (function) mine was crashing, only mine didn't give a line number I don't think!
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 03:41:52 am
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):
Code: [Select]
        <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:

Code: [Select]
                <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...?
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 03:42:10 am
It's obvious. Unchecked pointer.

Code: [Select]
if(!m_pNotebook) return 0;
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 07:28:09 am
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):

Code: [Select]
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:
Code: [Select]
(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.
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 07:34:44 am
How did you get it to load in the debugger??

I keep getting this  :x :x

http://forums.codeblocks.org/index.php?topic=1653.0

Only this time it's not with bf2.cpp, it's with the Code::Blocks files.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 07:38:11 am
hum.  just out of curiosity I changed it to:

Code: [Select]
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).

Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 07:43:04 am
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.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 08:30:47 am
Yeah, I just changed it back and forth, and now it compiles to the same code...so no idea
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 09:26:41 am
I'm working on it but... not getting anywhere.  :?
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 09:44:15 am
Ok I got it to compile in Unicode. My dear....

Now, I wonder if I fixed that bug... probably not. :o
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 10:13:16 am
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.
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 11:43:55 am
Maybe not necessary any more (rewriting TiX).
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 01:36:14 pm
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.
Title: Re: unknown exception
Post by: 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 :)
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 03:39:13 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?
Title: Re: unknown exception
Post by: rickg22 on December 16, 2005, 05:16:16 pm
Should I add it to SourceForge too since I already posted it, but not in the right place?

Yes! VERY YES!
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 05:19:51 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:
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 05:51:21 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. ;)
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 06:15:50 pm
The wxChar* doesn't compile (it's expecting wxCharBuffer).  Anyway the following does:

Code: [Select]
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).
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 06:18:05 pm
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.
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 06:26:06 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.
Title: Re: unknown exception
Post by: rickg22 on December 16, 2005, 06:41:24 pm
280: Just submit the showstopper patch... we don't mind how old it is, we can work around that. Just submit it please.
Title: Re: unknown exception
Post by: mandrav on December 16, 2005, 06:48:36 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.
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 07:17:50 pm
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. :)
Title: Re: unknown exception
Post by: 280Z28 on December 16, 2005, 07:25:22 pm
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. :(
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 07:34:09 pm
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.
Title: Re: unknown exception
Post by: killerbot on December 16, 2005, 07:43:53 pm
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
Title: Re: unknown exception
Post by: rickg22 on December 16, 2005, 07:50:07 pm
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.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 08:09:16 pm
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
Code: [Select]
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:
Code: [Select]
        <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
Code: [Select]
    pSlideBar->LoadFromStream( ms );

I would check the memory management stuff.  Definately looks like heap corruption.
Title: Re: unknown exception
Post by: rickg22 on December 16, 2005, 08:24:43 pm
http://wxextended.sourceforge.net/docs/slidebar_8cpp-source.html <- here's the sourcecode for wxExtended's slidebar.cpp. Is that it?
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 08:37:00 pm
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:
Code: [Select]
    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
Code: [Select]
    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:

Code: [Select]
                <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...

Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 08:42:15 pm
ahh... uncheck return value:

main.cpp:800 (LoadWindowState())

Code: [Select]
    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
Code: [Select]
    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
Code: [Select]
    wxMemoryInputStream ms(buf.c_str(), buf.Length());
    pLayoutManager->LoadFromStream( ms );
    pSlideBar->LoadFromStream( ms );

code for the case when buf == wxEmptystring.
Title: Re: unknown exception
Post by: rickg22 on December 16, 2005, 08:47:28 pm
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.
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 09:01:40 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 :)
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 09:05:08 pm
1) 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 :)
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 09:23:08 pm
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:

Code: [Select]
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]
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 09:26:06 pm
There is no 0x00 in a bin64 encoded string :)  Luckily, or we couldn't do that :)

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+   <---  these are all.


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"
Right, but the data really looks like this. This is correct. And wxString is meant to hold 0x00 values. This certainly works.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 09:29:06 pm
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.
Title: Re: unknown exception
Post by: 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?

Code: [Select]
    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
Code: [Select]
    stream.Read( &size, sizeof( size ) );

sets size to 1392520448.  We then allocate a buffer:
Code: [Select]
    char* psz = new char[size + 1];
whoops.
Title: Re: unknown exception
Post by: thomas on December 16, 2005, 09:37:57 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.

Code: [Select]
    wxMemoryInputStream ms(buf.c_str(), buf.Length());
                                        ^^^^^^^^^^^^

This one is safe to be used with 0x0, the other is not.
Title: Re: unknown exception
Post by: grv575 on December 16, 2005, 09:44:35 pm
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]
Title: Re: unknown exception
Post by: killerbot on December 16, 2005, 11:05:05 pm
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.
Title: Re: unknown exception
Post by: thomas on December 17, 2005, 12:56:17 am
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.
Title: Re: unknown exception
Post by: takeshi miya on December 17, 2005, 01:35:25 am
I don't understand this, in wx/mstream.h the ctor is defined as

Code: [Select]
wxMemoryInputStream(const void *data, size_t length);and not as
Code: [Select]
wxMemoryInputStream(const char *data, size_t length);
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 01:48:16 am
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.
Title: Re: unknown exception
Post by: thomas on December 17, 2005, 01:52:57 am
I don't understand this, in wx/mstream.h the ctor is defined as
Code: [Select]
wxMemoryInputStream(const void *data, size_t length);and not as
Code: [Select]
wxMemoryInputStream(const char *data, size_t length);
No...?
Quote from: http://www.wxwidgets.org/manuals/2.6.2/wx_wxmeminputstream.html#wxmeminputstream
wxMemoryInputStream::wxMemoryInputStream

wxMemoryInputStream(const char * data, size_t len)

Apart from that, sizeof(void) == sizeof(char) so it would not matter anyway.
Title: Re: unknown exception
Post by: 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).

[attachment deleted by admin]
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 02:26:15 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  :)
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 02:31:42 am
It'll work if you change everything in appglobals.h back to #define statements



[attachment deleted by admin]
Title: Re: unknown exception
Post by: 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...
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 02:49:26 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
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 02:59:22 am
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.
Title: Re: unknown exception
Post by: grv575 on December 17, 2005, 03:06:25 am
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.
Title: Re: unknown exception
Post by: grv575 on December 17, 2005, 03:21:38 am
One thing.  This gives a crc of 0:
Code: [Select]
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):

Code: [Select]
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 ???
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 03:34:12 am
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   :?

Code: [Select]
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 ) ;
}
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 04:31:58 am
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]
Title: Re: unknown exception
Post by: grv575 on December 17, 2005, 07:55:48 am
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)) :

Code: [Select]
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>
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 08:12:42 am
We aren't new to the highlighting bug.

http://sourceforge.net/tracker/index.php?func=detail&aid=1372906&group_id=126998&atid=707416
Title: Re: unknown exception
Post by: 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)
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 08:18:20 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: ).
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 08:23:06 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.
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: 280Z28 on December 17, 2005, 02:49:28 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.
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: Urxae on December 17, 2005, 02:58:38 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?
Title: Re: unknown exception
Post by: thomas on December 17, 2005, 04:03:24 pm
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).
Title: Re: unknown exception
Post by: rickg22 on December 17, 2005, 05:11:43 pm
So, is it fixed or not? (Just wondering)
Title: Re: unknown exception
Post by: thomas on December 17, 2005, 05:20:55 pm
Yes :)
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: takeshi miya on December 18, 2005, 02:01:22 am
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 64

OS: 32 bits
long=32 bits
int=32 bits

OS: 64 bits
long=64 bits
int=32 bits
Title: Re: unknown exception
Post by: grv575 on December 18, 2005, 04:25:07 am
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)
Title: Re: unknown exception
Post by: 280Z28 on December 18, 2005, 10:07:18 am
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)!!

Quote
We're Sorry.
The SourceForge.net Website is currently down for maintenance.
We will be back shortly
Title: Re: unknown exception
Post by: 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.
Title: Re: unknown exception
Post by: 280Z28 on December 18, 2005, 06:01:56 pm
It is using wxUInt32 now, that is as much cross-platform-32bits as we can get.

Yep, that's the one :)