unknown exception

[rickg22]

280: Just submit the showstopper patch... we don't mind how old it is, we can work around that. Just submit it please.

[mandrav]

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.

[280Z28]

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.

[280Z28]

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.

[grv575]

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.

[killerbot]

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 ... 

Cheers,
Lieven

[rickg22]

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.

[grv575]

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

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

        <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

    pSlideBar->LoadFromStream( ms );

I would check the memory management stuff.  Definately looks like heap corruption.

[rickg22]

http://wxextended.sourceforge.net/docs/slidebar_8cpp-source.html <- here's the sourcecode for wxExtended's slidebar.cpp. Is that it?

[grv575]

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

    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

    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

                <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...

[grv575]

ahh... uncheck return value:

main.cpp:800 (LoadWindowState())

Code

    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

    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

    wxMemoryInputStream ms(buf.c_str(), buf.Length());
    pLayoutManager->LoadFromStream( ms );
    pSlideBar->LoadFromStream( ms );

code for the case when buf == wxEmptystring.

[rickg22]

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.

[thomas]

...

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

[thomas]

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

[grv575]

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

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]