Ok now i get close to solving the problem. My original class is the following: class queue : public queue_set { public: queue(){}; virtual ~queue(){}; void AddQuery(query::pointer Query); void RmQuery(query::pointer Query); void Update(query::pointer Query); boost::mutex m_Queue; typedef boost::shared_ptr<queue> pointer; }; With: void queue::AddQuery(query::pointer Query) { boost::mutex::scoped_lock lm_Queue(m_Queue); insert(Query); } void queue::Update(query::pointer Query) { boost::mutex::scoped_lock lm_Queue(m_Queue); queue_by_id::iterator it=get<tid>().find(Query->id); get<tid>().replace(it,Query); } void queue::RmQuery(query::pointer Query) { boost::mutex::scoped_lock lm_Queue(m_Queue); queue_by_id::iterator it=get<tid>().find(Query->id); get<tid>().erase(it); } If i use it in the example jung.cpp it works. My real world program works without these 4 lines: void AddQuery(query::pointer Query); void RmQuery(query::pointer Query); void Update(query::pointer Query); boost::mutex m_Queue; but not with them enabled! Ok after playing a little bit around with them, i can say the following: Enabling just one of these procedures in my real program -> i get the crash. No function, everything fine. Whats going on here??? These are not called in the constructor!? Up to now they are never ever called! (But i need them of course ;-)) So whats going on, im frightend.. bye Manu
Joaquín Mª López Muñoz wrote:
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.
I dont know if its a compiler issue, but i didnt used multi_index with another compiler than g++ 4.0.2. Before i was working with the latest 3.x (stable of course). But this was version from here away. So i consider it is no problem of the compiler at first, because i use about 4 or 5 libraries and dont want to recompile them all before trying other things..
is there a way i can get the compiler version a library was compiled with?
I don't know. Sorry.
[...]
no problem.. still smarter than me *g*
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.)
uhh that goes deep in the libstdc++.. :-/ I dont have a clue where to begin with it. i would just stop here and try another way, because i dont think that my code is perfect here.. and i really dont have the time at the moment searching a stdlib bug...
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...
You could be right here. I have just rewrote the whole managing part of my program. im not sure what could overwrite something, but i think i ahve to reread most of the code now, and test. i have wrote a test program with the whole stucture which seems to matter for the multi_index queue class and it works just fine with no errors. So i have to begin to look of the road..
But its interesting that i can call an instance of queue_set, which works, but no instance of queue. This is kinda weird, isnt it? And i even added in the examples exactly all the stuff i have in the real program and there it still works. (it not very much up to here. just some stuff for gurantee thread safe inserts and a few often used functions.
Greetings Manuel Jung
Ps.: And searching.. and searching...
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users