Please set the following environment variable G_SLICE as before launching Code::Blocks-

export G_SLICE=always-malloc

This should solve your problem.

Thanks for your reply but export G_SLICE=always-malloc did not fix the problem. I did set this in Settings > Environment > environment settings and also tried it from the console but it makes no difference. I looked up glibc and G_SLICE=always-malloc and it seems more applications in Linux suffer from memory leakage like problems. Is this a glibc problem and not a wxSmith problem?

I've just found out it's possibly a privileges problem. Why didn't I think of this earlier! If I simply do sudo codeblocks I can open my wxs in wxSmith without crashing and use the preview button which caused crashing also. I'm very happy, I can work again!

But seriously, Code::Blocks should work without root privileges, right?

I have the same problem, and

export G_SLICE=always-malloc

doesn't help. Running C::B as root doesn't help also.

My systems - mandriva 2008.1/x86_64 and mandriva 2009.0 (unstable development)/x86_64 on two different hardware configs (Athlon 64 & Core 2 Duo).

Tested versions of C::B - 8.02 and svn5093

Steps to reproduce the bug:

1. Start C::B and create new wxWidgets dialog-based project with wxSmith and all default settings.

2. Open its dialog and remove all controls and sizers (including root wxBoxSizer:BoxSizer1) - it should become just an empty square form with dotted grid.

3. Add wxSpinCtrl (without any sizers). It occupies the whole form (strange... another bug?).

4. Add another wxSpinCtrl - just put it over the firts one. Both controls become of the normal size and you can drag them to place correctly.

5. Save all files and close C::B.

6. Reopen C::B, load this project and try to open our dialog with two wxSpinCtrl controls for editing. C::B crashes. You will never be able to open this dialog again - only on 32-bit system (maybe)...

BTW I've tried to use other controls (not everyone), but they seem to work correctly - no crashes after reopening dialog for editing.

After my initial cheerful announcement that running Code::Blocks as root solved the wxSmith crash I sadly have to say the problem came back although less frequently.

Nevertheless, when a form has crashed it can't be recovered so I resorted to setting up forms in wxSmith and then editing them manually. I'm glad to see another user reported the problem.

I hope something can be done about it because I still love wxSmith, especially because it's the only good free alternative.

I have found the problem!

wxSmith crashes on forms loading due to the stupid bug: in some components their numeric properties are declared as 'int' while they are saved in file (and reading from file) as 'long'. On Linux/x86_64 this types interchanging causes memory overflow as sizeof(int)=4 while sizeof(long)=8.

To fix this you should go to the directory

<root_cb_sources>/src/plugins/contrib/wxSmith/wxwidgets/defitems , check all properties of all components - how they are declared and which macro (WXS_LONG or some other) is used to manipulate them - and fix if needed. Especially this is the case for spin button & spin control, but maybe also for some other widgets.

Good luck!

I think olelukoie struck gold. Because I use both 32 and 64-bit systems with SVN in between, I think my code gets sort of "infected" with this long/int difference after which I can't use it any more on both systems.

I'm going to try and reproduce this by only using wxSmith on my 32-bit machine and see what happens.

(I'm silently hoping this cures it and it'll be fixed in the next Ubuntu release).

I just submitted a patch (#2516).

Fixed by applying patch patch #2516, thanks!