Code::Blocks Forums
User forums => Help => Topic started by: zaleksf on August 16, 2009, 12:54:10 pm
-
I am using CB on Windows Vista32-sp2 with mingw-4.4.0 and wxWidgets-2.8.10. I can create and compile the 'Hello World' and other programs just fine. However, when I attempt to save a modified wxs resource file (modified using wxSmith beyond what was originally generated by the project set-up wizard) then CB crashes completely. Changes to the rest of the program are retained and changes to the .wxs file are not.
This problem occurs with CB versions 8.02 through svn build 5731. This problem does not occur for me on Ubuntu 9.04 (same builds).
Any thoughts on how to resolve this would be greatly appreciated.
-
Do you have a debug-report in the directory where C::B's is ?
Does it happen always, or does it depend on the changes you make ?
-
Hi Jens,
I ran gdb and submitted a report to the berlios site. Based on your prompting, I did find an error report in the CB folder - thanks! I didn't know that file was being generated. I've attached the codeblocks.rpt file.
The crash only happens when trying to save a file modified by wxSmith. It happens every single time. Otherwise CB seems to work excellently (works with gui files generated by wxFormBuilder, etc). The error report seems to indicate some issue with Dwarf (-unwinding, I'm assuming?). I compiled wxWidgets with MinGW32-4.4.0 (, with the following modules:
* binutils (binutils-2.19.1-mingw32-bin.tar.gz)
* mingw-runtime (mingwrt-3.15.2-mingw32-dev.tar.gz)
* w32api (w32api-3.13-mingw32-dev.tar.gz)
* mingw-utils (mingw-utils-0.3.tar.gz)
* mingw32-make (mingw32-make-3.81-20080326-3.tar.gz)
* gdb (gdb-6.8-mingw-3.tar.bz2)
I thought that I had selected the default Dwarf2 unwinding exception method (more conservative) for compiling wxWidgets, but upon inspection, that may not be true.
Please let me know if this information provides any clues for further action (recompiling wxWidgets, etc).
Regards,
Steve
[attachment deleted by admin]
-
I verified that I had NOT built the wxWidgets with Dwarf2 unwinding.
Steve
-
Hello,
I had exactly the same problem earlier. For me it occured only when building from SVN repository.
The problem comes from TinyXML library: when saving the wxs file (XML format), the plugin wxSmith calls TinyXMLDoc->Accept (or something like that). TinyXML is statically linked to wxSmithLib and to the codeblocks dll. It seems that the function to call can be either called in wxSmithlib, or in codeblocks.dll - and mixing the two results in crash.
The solution:
1 - download SVN snapshot from codeblocks + plugins
2 - compile codeblocks using these directions: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows (http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows)
3- before doing the step called "Compile contributed (or your own) plugins", do the following:
a - open the Contrib plugin workspace "ContribPlugins.workspace" (in dir "src")
b - activate "wxSmith" project (double-click on it in the tree)
c - go in menu "project" -> "build options", click on tab "linkers settings"
d - remove the line "txml" from the left pane. Make sure it does not appear in other sub-projects as well (wxPropertyGrid, wxSmithLib
, wxSmith) - see the screenshot (after removing the culprit line)
e - save the project (file - save project)
f - select menu "build - build workspace" and follow the instructions from the wiki
It worked like a charm for me (although it was not easy to find).
Maybe the Devs (which have done a great work by the way) will update the project options in SVN.
Good luck !
Sebastien
[attachment deleted by admin]
-
Yeah!!! :D
That worked!
Thanks, Sebastien - I was to the point of talking with tech support about a total rebuild of my system, trying to chase down a mysteriously corrupt system ntdll.dll, etc (that would have been ugly!). I am quite excited that I can now use CodeBlocks with wxSmith for Win and Linux development; the Devs have done quite a good job.
We can't be the only people who have run in to this - is there a way to get the word out? Is there a good reason for the txml library to be in the wxSmith plugin?
-
It might be a bug that occurs only on very specific conditions.
It is strange enough that I did not have any problems with the Nightly Build, but that I had problem only with versions built by myself. Therefore there might also be a compiler / linker configuration issue. I still do not really understand the root cause of the problem (why it leads to crash - I suspect objects are allocated with codeblocks.dll, and deallocated with wxsmithlib, leading to freeing memory at a null pointer).
The devs may want to test this workaround thoroughly before applying it - what works for us may break the building process on others configurations (leading to link errors with "symbol not found" while compiling wxsmithlib - or worse: silent bugs waiting to appear on specific conditions).
Let them say what they think about it. They will surely want to understand exactly what happened - and it might not be so easy.
Sebastien
-
I just had this same problem, and the fix reported by seb_seb0 worked great. The problem (as reported in the "codeblocks.rpt" file) appears to be in "tinystr.cpp", in function "TiXmlString::reserve"; this is a poorly-written function, that allows the possibility of copying data to un-allocated memory (it uses "memcpy", but does not check properly that the amount of data is too long for the allocated memory block).
However, using seb_seb0's fix, it all works now.
Would it make sense for the devs to "txml" from the linker portion of the wxSmith project?
Ringo
-
Would it make sense for the devs to "txml" from the linker portion of the wxSmith project?
It's already done.
On windows in svn r6128, on linux I did it some commits earlier.
-
It's already done.
On windows in svn r6128, on linux I did it some commits earlier.
Thank you! I'm using a somewhat earlier version, and so did not have it. I guess it's time to download something newer.
Ringo