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

From: Manuel Jung (gzahl_at_[hidden])
Date: 2007-02-15 14:24:12

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