MantisBT - JANA
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000299JANABugpublic2013-02-01 13:442013-03-01 16:39
Reporterdavidl 
Assigned Todavidl 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0000299: Protect some methods in JParameterManager with a mutex lock
DescriptionThis 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.

 - Paul"
Steps To Reproduce
Additional InformationI'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).
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-02-01 13:44davidlNew Issue
2013-02-11 14:39pmattAdditional Information Updated
2013-03-01 16:39davidlNote Added: 0000463
2013-03-01 16:39davidlStatusnew => resolved
2013-03-01 16:39davidlResolutionopen => fixed
2013-03-01 16:39davidlAssigned To => davidl

Notes
(0000463)
davidl   
2013-03-01 16:39   
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.