0000299: Protect some methods in JParameterManager with a mutex lock

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000299

JANA

Bug

public

2013-02-01 13:44

2013-03-01 16:39

Reporter

davidl

Assigned To

davidl

Priority

normal

Severity

minor

Reproducibility

have not tried

Status

resolved

Resolution

fixed

Platform

OS Version

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.

- Paul"

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.

Attached Files

Relationships

Notes
(0000463) davidl (administrator) 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.

Issue History
Date Modified	Username	Field	Change
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