DR 1.7.0... particle editor crashes DR

[PranQster]

If I try to select the particle editor, DM immediately crashes with a segmentation fault.

What libraries get called in linux for the particle editor, so I can try to update or replace with a different version? If it is libboost*.so.1.46.1, then I know what the problem is (I had to make symlinks from version 1.48.0 to get DR to run).

I had to install an Ubuntu package manually (decompress and copy) since I use an .rpm distro.

I would compile my own DR but cannot due to:

 

Making all in gtkutil
make[3]: Entering directory `/home/john/Desktop/darkradiant/libs/gtkutil'
 CXX	ConsoleView.lo
 CXX	Timer.lo
 CXX	WindowPosition.lo
In file included from ../../libs/gtkutil/IConv.h:4:0,
			 from ConsoleView.cpp:4:
/usr/include/glib-2.0/glib/gconvert.h:28:2: error: #error "Only <glib.h> can be included directly."
In file included from ../../libs/gtkutil/IConv.h:5:0,
			 from ConsoleView.cpp:4:
/usr/include/glib-2.0/glib/gmessages.h:28:2: error: #error "Only <glib.h> can be included directly."
In file included from ../../libs/gtkutil/IConv.h:6:0,
			 from ConsoleView.cpp:4:
/usr/include/glib-2.0/glib/gunicode.h:23:2: error: #error "Only <glib.h> can be included directly."
In file included from ../../libs/gtkutil/IConv.h:7:0,
			 from ConsoleView.cpp:4:
/usr/include/glib-2.0/glib/gmem.h:28:2: error: #error "Only <glib.h> can be included directly."
 CXX	PersistentTransientWindow.lo

Anyone know about that?

Edit:

I got it to continue compiling, first by changing IConv.h to be like the following:

 

#include <glib-2.0/glib.h>
/** #include <glib/gconvert.h>
* #include <glib/gmessages.h>
* #include <glib/gunicode.h>
* #include <glib/gmem.h>
*/

Then I had many libraries (mostly devel) missing .la files and found that many of Mageia's libraries do not include those along with the .so files. But most of Mandriva's libraries still do have the .la files, so I painstakingly hunted those packages down until make continued. Now I'm back to the first problem with the glib.h error, so I need to modify many header files in the libs/gtkutil/ path like I did above.

 

But now seeing that Baal has the crash with 1.70 compiled from SVN, I probably will not bother continuing to compile until that is sorted out.

Edited November 28, 2011 by PranQster

[greebo]

How about using a stable standard distribution once in a while?

 

Sorry, couldn't resist, but it appears to me you're making your own life harder just because you can. If it's a standard distro I might even install it in a virtual machine and look at it, but I definitely won't bother installing an unsupported alpha version.

 

It appears you're using GTK+ 3 headers and/or all preprocessor symbols are set to disable deprecated interfaces. In GTK+2 it was allowed to specifically include only the gtk/glib headers you need in the translation unit, but in GTK+3 they disabled that and only allow inclusion of one central file (how that should be better for compilation performance who knows, the headers are huge). Somehow your distro is set to that mode.

 

On a related note, copying packages from other distros is like asking for trouble, who knows what those binaries have been linked against.

[PranQster]

LOL, but that would be too easy. Thanks though

I've been tinkering like this for years, so I'm used to the possibility of breaking the system. As far as distro package swapping goes, I keep it between Mageia and Mandriva since they are basically identical twins. Mandriva has a more complete package set, so I sometimes grab stuff from it. I have, in the past, mixed in some packages from openSuse and fedora, with varied results. But not much of that in my current installation.

The particle editor is no big deal right now. I was not needing to use it and was just loading it to check it out. So far all the rest of DR works as it should, so I'll just soldier-on and not worry about it.

If I get desperate, I have another machine I can put a standard, stable distro on.

[Baal]

The editor crashes for me too when I try to open the particle editor. It's 1.7.0 compiled from svn running on Arch linux. I can give a stack trace after the segmentation fault. If I had a clue how debugging on linux works I would do more.

[greebo]

What's the stacktrace, can you post some details?

[Baal]

Here it is:

 

#0  compare (__str=..., this=0xbfffe538) at /usr/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/basic_string.h:2176
#1  operator< <char, std::char_traits<char>, std::allocator<char> > (__rhs=..., __lhs=...) at /usr/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/basic_string.h:2512
#2  operator() (__y=..., __x=..., this=<optimized out>) at /usr/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/stl_function.h:236
#3  std::_Rb_tree<std::string, std::pair<std::string const, Gtk::TreeIter>, std::_Select1st<std::pair<std::string const, Gtk::TreeIter> >, std::less<std::string>, std::allocator<std::pair<std::string const, Gtk::TreeIter> > >::_M_insert_unique (this=0xb6869ff4, __v=...) at /usr/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/stl_tree.h:1267
#4  0x08245131 in insert (__x=<optimized out>, this=<optimized out>) at /usr/lib/gcc/i686-pc-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/stl_map.h:518
#5  operator() (def=<optimized out>, this=<optimized out>) at ui/particles/ParticlesVisitor.h:53
#6  boost::detail::function::void_function_obj_invoker1<ui::ParticlesVisitor, void, particles::IParticleDef const&>::invoke (function_obj_ptr=..., a0=...) at /usr/include/boost/function/function_template.hpp:153
#7  0xb47b7138 in operator() (a0=<optimized out>, this=0xbfffe638) at /usr/include/boost/function/function_template.hpp:760
#8  particles::ParticlesManager::forEachParticleDef(boost::function<void (particles::IParticleDef const&)> const&) const (this=0x8693d10, v=...) at ParticlesManager.cpp:60
#9  0xb47e502f in ui::ParticleEditor::populateParticleDefList (this=0x8693d10) at editor/ParticleEditor.cpp:137
#10 0xb47e56ff in ui::ParticleEditor::setupParticleDefList (this=0xbfffe8d4) at editor/ParticleEditor.cpp:124
#11 0xb47ed649 in ui::ParticleEditor::ParticleEditor (this=0xbfffe8d4, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at editor/ParticleEditor.cpp:94
#12 0xb47edebb in ui::ParticleEditor::displayDialog (args=...) at editor/ParticleEditor.cpp:1289
#13 0xb486875f in operator() (a0=..., this=0xd45526c) at /usr/include/boost/function/function_template.hpp:760
#14 cmd::Command::execute (this=0xd455268, args=...) at Command.h:69
#15 0xb48628b6 in cmd::CommandSystem::executeCommand (this=0x86904d0, name=..., args=...) at CommandSystem.cpp:344
#16 0xb4865f91 in cmd::CommandSystem::execute (this=0x86904d0, input=...) at CommandSystem.cpp:298
#17 0xb44f0662 in execute (this=0xd52d8b0) at Statement.cpp:30
#18 Statement::execute (this=0xd52d8b0) at Statement.cpp:27
#19 0xb44f05af in Statement::onMenuItemClicked (this=0xd52d8b0) at Statement.cpp:95
#20 0xb44f1172 in operator() (this=0xd51b2fc) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787

...

 

I don't really know the code. But I saw a map containing iterators. Maybe it's a problem with an iterator becoming invalid?

[OrbWeaver]

I can reproduce that error in Linux.

 

greebo: it looks like there are two different classes called ui::ParticlesVisitor, one defined in radiant/ui/particles/ParticlesVisitor.h and taking three arguments, and the other in plugins/particles/editor/ParticleDefPopulator.h which takes two arguments. It looks like the crash happens because the method with three arguments is being called when only two were actually given at the call site.

 

I suspect this problem appears on Linux because of the different linking behaviour: having identically-named symbols in both a linked .so and the main executable will cause problems since there is a single flat namespace. I suspect that using a unique C++ namespace like "particles" rather than re-using "ui" in a plugin would solve the problem. EDIT: Never mind, I fixed it.

Edited November 28, 2011 by OrbWeaver

[OrbWeaver]

Fixed as of revision 6812.

[PranQster]

Cool. Looks like I'll have to wait for a packaged build since compiling is a mess for me with Mageia Cauldron.

[Baal]

Thanks Orbweaver. I build 6812 and the particle editor seems to work now.

 

But there's a small problem with boost::filesystem::path 1.47.

The method 'game::Manager::getUserEnginePath()' now returns a path without a trailing slash and in 'game::Manager::constructPaths()' the game rsp. baseGame directory names are appended to it without the slash.

 

I modified it but I don't know whereelse in the code this may be a problem.

[PranQster]

Any possibility one of you could tar.gz or .zip your build 6812 /usr/share/darkradiant/ directory along with /usr/bin/darkradiant binary and pm me with a link to it?? Please? If our boost versions differ, etc., it's no big deal. I can make symlinks to make it run.

[Baal]

Would that even work? They're built with a different compiler version than your libraries, configured on a different system and so on.

[OrbWeaver]

But there's a small problem with boost::filesystem::path 1.47.

The method 'game::Manager::getUserEnginePath()' now returns a path without a trailing slash and in 'game::Manager::constructPaths()' the game rsp. baseGame directory names are appended to it without the slash.

 

Thanks, I'll look into that.

Any possibility one of you could tar.gz or .zip your build 6812 /usr/share/darkradiant/ directory along with /usr/bin/darkradiant binary and pm me with a link to it?? Please? If our boost versions differ, etc., it's no big deal. I can make symlinks to make it run.

 

I will push a new release to Launchpad, and you can extract the contents of the .deb, that's probably the easiest way. I share Baal's doubts as to whether it will work though: if the distribution you are using is different enough to not be able to compile DR successfully, it seems likely that the binary won't be all that compatible either.

[PranQster]

Thanks, I'll look into that.

 

 

I will push a new release to Launchpad, and you can extract the contents of the .deb, that's probably the easiest way. I share Baal's doubts as to whether it will work though: if the distribution you are using is different enough to not be able to compile DR successfully, it seems likely that the binary won't be all that compatible either.

So far I have almost entirely used DR extracted from the ubuntu packages. I was previously able to compile it with Mandriva 2010 and 2010.1, but more recent versions have not bee successful.

After copying the ubuntu version into my system, I normally need to make symlinks from the boost libraries and the gtk libraries from what I have installed to the versions DR is trying to use. So far this has worked pretty well. Both of my released missions thus far were built on DR ubuntu versions.

The worst I have seen so far is a random crash which closes DR when I press a keyboard shortcut, such as 's' for the texture tool or 'esc' to unselect an object. But that is rather rare and I am in the habit of saving often and keeping a backup.

 

If the question "Why don't you just use Ubuntu?" comes up, my extremely polite answer is this:

I really don't like Ubuntu very much and much prefer the well-stocked package repositories for Mandriva/Mageia.

I am running openSuse 12.1 on my laptop and enjoying it rather well and may migrate to it on my desktop if I don't like the direction Mageia goes in.

Edited December 1, 2011 by PranQster