Re: [Boost-users] [multi_index] SIGABRT in multi_index_container constructor

From: Manuel Jung (gzahl_at_[hidden])
Date: 2007-02-15 15:00:01

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_at_[hidden] 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users