[SERVER-3335] Probably undefined behaviour Created: 25/Jun/11 Updated: 12/Jul/16 Resolved: 26/Jun/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 1.9.0 |
| Fix Version/s: | 1.9.1 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Matthew Sherborne | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | replication, threads | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
N/A |
||
| Operating System: | ALL |
| Participants: |
| Description |
|
In the latest git pull I noticed the following: db/repl.h:89 - unique_ptr<ThreadPool> tp; db/repl.c:353 - v.push_back( shared_ptr< ReplSource >( new ReplSource( s ) ) ); As there is no copy contructor for ReplSource .. if 's' has a 'tp' assigned, something bad will happen. Most likely the new ReplSource will get the first ReplSource's thread pool, and the first one's will become null. Probably the designed behaviour would be to have the new ReplSource build its own thread pool, and not steal 's's one. I guess the fix would be to give ReplSource a copy constructor, that handles auto_ptr<ThreadPool> correctly (by leaving the original, and creating a new one for the new copy). |
| Comments |
| Comment by auto [ 26/Jun/11 ] |
|
Author: {u'login': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: safer access |