----- Mensaje original -----
De: Manuel Jung
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; }; [...] 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..
Well, I might be totally wrong, but the more you describe the problem the more it looks to me like some neighboring variable corrupting the space occupied by your queue object. I've got several questions and suggestions to try to test whether this hypothesis is true: 1. The crashing queue object, is it a gobal variable? If so, can you try moving its definition so as to displace it with respect to other global variables in the same translation unit? I mean, if your code looks like: some_type1 var1; some_type2 var2; queue q; some_type3 var3; try shuffling it a bit like vg: queue q; some_type1 var1; some_type2 var2; some_type3 var3; You get the idea. 2. [assuming the object is global] If there are no neighboring vars, try planting some safe areas around the queue object: char pre[256]; queue q; char post[256]; 3. [assuming the object is global] Try, just for testing purposes, to momentarily comment the offending queue out and declaring a queue object as a stack variable: int main(){ queue q; ... } Crash/no crash? 4. Last of all, your problem involves an internal mutex object which is only defined when you set Boost.MultiIndex safe mode on (you've got it set on, right?) If you turn this mode off you won't get the crash, but this is IMHO just masking the actual problem, which could appear under a different guise later on. Good luck, please keep me informed, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo