-
Notifications
You must be signed in to change notification settings - Fork 57
[OVEP] Fixed coverity issues #687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -32,12 +32,16 @@ void* OVRTAllocator::Alloc(size_t size) { | |||||
|
|
||||||
| void OVRTAllocator::Free(void* p) { | ||||||
| try { | ||||||
| ov::Tensor* tensor = nullptr; | ||||||
| { | ||||||
| std::unique_lock lock(mutex_); | ||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For automatic mutex unlocking you can use lock guards like below, this approach is much safer -
Suggested change
The
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Placing the delete operation within the scoped critical section results in a Coverity medium-severity. Additionally, since delete is a relatively time-consuming operation, which can potentially block other threads, so I placed the delete operation outside, which will decrease the time for my critical section. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure. can you use the lock_guards instead for both Alloc() & Free() calls like mentioned above as you are removing lock.unlock() in your change ( this might lead to deadlocks, perf degradation, logical errors), this will ensure auto unlocking mechanism. This is much simpler to manage & execute the flow without having to unlock the mutes
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ig, this ca n still go in, we can change this later, this needs to go in today due to some release issues, can you please approve this for now and i can make the change later, may be next week |
||||||
| auto it = allocated_.find(p); | ||||||
| if (it != allocated_.end()) { | ||||||
| ov::Tensor* tensor = it->second; | ||||||
| tensor = it->second; | ||||||
| allocated_.erase(it); | ||||||
| lock.unlock(); | ||||||
| } | ||||||
| } // lock will be automatically released when it goes out of scope | ||||||
|
Comment on lines
+36
to
+43
|
||||||
| if (tensor) { | ||||||
| delete tensor; | ||||||
| } | ||||||
| } catch (const ov::Exception& e) { | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] Moving
ov_coreintoParseDeviceTypeisn’t necessary since it isn’t reused afterward. Consider passingov_coreby const reference or by value withoutstd::moveto preserve clarity of ownership semantics.