unknown exception

[thomas]

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.

[grv575]

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.

[grv575]

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

    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

    stream.Read( &size, sizeof( size ) );

sets size to 1392520448.  We then allocate a buffer:

Code

    char* psz = new char[size + 1];

whoops.

[thomas]

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

    wxMemoryInputStream ms(buf.c_str(), buf.Length());
                                        ^^^^^^^^^^^^ 

This one is safe to be used with 0x0, the other is not.

[grv575]

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]

[killerbot]

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.

[thomas]

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.

[takeshimiya]

I don't understand this, in wx/mstream.h the ctor is defined as

Code

wxMemoryInputStream(const void *data, size_t length);

and not as

Code

wxMemoryInputStream(const char *data, size_t length);

[280Z28]

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.

[thomas]

I don't understand this, in wx/mstream.h the ctor is defined as

Code

wxMemoryInputStream(const void *data, size_t length);

and not as

Code

wxMemoryInputStream(const char *data, size_t length);

No...?

wxMemoryInputStream::wxMemoryInputStream

wxMemoryInputStream(const char * data, size_t len)

Apart from that, sizeof(void) == sizeof(char) so it would not matter anyway.

[thomas]

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]

[280Z28]

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 

[280Z28]

It'll work if you change everything in appglobals.h back to #define statements



[attachment deleted by admin]

[thomas]

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

[280Z28]

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