gzahl@arcor.de ha escrito:
Hi,
Hello Manuel,
Hi,
Im defining a class with a multi_index_container as base. When i construct a instance of this class, and the multi_index_container is called, the program crashes. It even crashes, when i dont use it as a base class. [...] This compiles just fine, but if i run the code i get the following backtrace after a Sigmentation Abort. It happens, when the queue::queue() is called. Someone a idee whats it about? Im new to boost::multi_index, so maybe i misunderstud something? Thank you
Well, what you're doing is AFAICS correct, so you shouldn't be getting this crash. You haven't provided a complete test program showing producing the crash, so I wrote one myself after what you've shown and tried it locally, no problems here. Could you please try the attached jung.cpp file? Does it crash also? If it doesn't then there's more to your program than you have described, maybe you can send compilable program showing the issue. If jung.cpp crashes, then could you please provide the following info?
The Testprogramm jung.cpp does not crash on my machines (im testing on a ubuntu 6.10 and a debian 3.1 system, both working with g++ 4.0.2) I will try to get a example which reproduces my error, but in the meantime i was thinking about the libc stuff. Maybe this is the real problem thing? i changed to 4.0.2 from a 3.x version just some weeks ago, so maybe here is the problem, because some lib im using is not compiled with 4.0.2?
It could be. Was everything working OK before switching to 4.0.2? Did you do any significant change to the code after the switch? Can you, just for testing, revert to 3.x and see what happens? Or alternatively, can you do a full build of all the modules invovled? I'm no GCC expert, but if your x in 3.x is less than 4, then there's definitely a C++ ABI change between that and GCC 4.0.2.
is there a way i can get the compiler version a library was compiled with?
I don't know. Sorry. [...]
2. The stacktrace mentions a failed assertion in libc.so. Can you see the source code that's causing the assertion? Maybe it sheds some light.
Im not sure about, where to see this sourcecode?
scoped_lock(lightweight_mutex & m): m_(m.m_) { pthread_mutex_lock(&m_); }
these are the lines alst mentioned in the backtrace "/usr/local/include/ boost/detail/lwm_pthreads.hpp:72" from #5. But this is not what you meant, right?
No. The assertion is happening inside libc.so, this is the interesting source code to look at. Again, I'm no GCC expert, but maybe there's some way to link against a debug version of the runtime lib which contains this info (much as your compiled modules have.) Another thing to consider: Have you recently made canges to your code related to the construction of *another* global variables? What I'm thinking of is, if you have some out-of-bounds overwrite somewhere this could be somehow damaging the info inside a neighboring multi_index_container. Just a wild guess... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo