Opened 13 years ago
Closed 13 years ago
#3272 closed Bugs (invalid)
Boost::shared_ptr crash when used in stl queue
Reported by: | Owned by: | Peter Dimov | |
---|---|---|---|
Milestone: | Boost 1.40.0 | Component: | smart_ptr |
Version: | Boost 1.37.0 | Severity: | Problem |
Keywords: | Boost::shared_ptr crash | Cc: |
Description
Hi, We have a scenario where we are storing instances of boost::shared_ptr in a stl queue. Then we pop the data out of Queue and do further processing. If i am correct then the pop() provided by stl queue calls the destructor of the object being popped out(which in this case would be boost::shared_ptr instance). This happens in a continuous daemon process which crashes at some random point say after 6 or 8 hrs because of boost pointer corruption. Am provding a small template below as per our implementation.
boost::shared_ptr<Sample> spSample; spSample.reset(new Sample()) ;
queue.push(spSample) ;
The below processing happens in a thread. No object is being shared between threads. Each thread has its own stl queue into which the data is pumped in by parent thread as shown above. boost::shared_ptr<Sample> spSample1 = q.front() ; q.pop() ; Will call the destructor of the shared_ptr at q.front()
some function called which takes spSample1 as paramater func(spSample1) ;
Is it safe to use boost::shared_ptr with stl queue ??
We are using version 1.33.1.
Change History (2)
comment:1 by , 13 years ago
Component: | Regression Testing → smart_ptr |
---|---|
Owner: | changed from | to
Severity: | Regression → Problem |
Summary: | Boost::sherad_ptr crash when used in stl queue → Boost::shared_ptr crash when used in stl queue |
comment:2 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Closing - we can't do anything without a test case that reproduces the problem.
It should be safe to use shared_ptr with std::queue.
I don't understand exactly what you are doing.
Does the parent thread write to the queue while the child thread is reading from it or does the parent thread fill the queue completely before launching the child?
I'm assuming that this problem is reproducible. If you leave the process running long enough it will eventually crash.
Unless you can provide a reduced test case, I doubt that there is much I can do to trace the problem.