|Anonymous | Login | Signup for a new account||2020-09-21 22:30 EDT|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000299||JANA||Bug||public||2013-02-01 13:44||2013-03-01 16:39|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0000299: Protect some methods in JParameterManager with a mutex lock|
|Description||This is from Paul Mattione and his original e-mail is quoted below.|
Some methods of JParameterManager (e.g. WriteConfigFile) do not lock the "parameter_mutex" while reading the parameter values. Because the values are stored as string types, if a value is being changed while it's being read, the string data may be re-allocated at just the wrong time causing the reader to try using a stale pointer. This leads to crashes. The JParameterManager methods should be modified to lock the mutex when reading to ensure the underlying string's pointer is not modified during the process.
Here is Paul's e-mail sent on Feb. 1st describing the problem.
"Hey David, in the JParameterManager::PrintParameters() function, can you please insert a lock on the "parameter_mutex" before printing the actual values to screen? (locks should probably be placed in the WriteConfigFile, GetParameters(map), etc. functions too...) I'm having crashes where one thread tries to read/write parameter values while another thread is printing to screen. This is probably happening because I'm doing something unexpected:
I have the functions to open, write-to, and close the output BOS file stored in a persistent factory object (is there a better way to do this? I don't want this in a plugin: I want every plugin to be able to call this (e.g. only write if pass certain cuts)). Because of this, once one thread opens the BOS file, it needs to tell the other threads the BOSIOptr location for writing. I do this (with an int) via gPARMS (is there a better way to pass info between threads?).
Perhaps the reason I'm seeing the crashes is because I have it open the BOS file in the evnt() method; I'm moving it to the init() method and that should (may?) probably remove all of the crashes I'm seeing anyway. However, I need to still modify gPARMS in the persitent-object destructor: I need to know how many threads are remaining, so that I don't close the output BOS file until the last one is done. So this could potentially still cause more crashes. Is there a better way of doing this?
Thanks again David.
|Additional Information||I've also encountered a crash when jana::JParameterManager::PrintParameters() isn't called until the end of the program (I ran with 4 threads on 100 events of data, and it crashed in that function while simultaneously merging the threads).|
|Tags||No tags attached.|
A fix for this was put in revision 1238 and will appear in jana 0.0.6.
Mutex lock/unlock calls were added to WriteConfigFile and PrintParameters methods of JParameterManager. This should address the specific problem Paul was seeing.
This does not necessarily make the system bomb-proof. It is still possible for a user to get a hold of a JParameter object and then modify the value while another thread reads it.
|2013-02-01 13:44||davidl||New Issue|
|2013-02-11 14:39||pmatt||Additional Information Updated|
|2013-03-01 16:39||davidl||Note Added: 0000463|
|2013-03-01 16:39||davidl||Status||new => resolved|
|2013-03-01 16:39||davidl||Resolution||open => fixed|
|2013-03-01 16:39||davidl||Assigned To||=> davidl|
|Copyright © 2000 - 2020 MantisBT Team|