Closed Bug 1247636 Opened 8 years ago Closed 7 years ago

[Static Analysis][Resource leak] In Function createThreadCursor::run and getThreadFromCursorAndNotify

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: andi, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: coverity, Whiteboard: CID 119596, CID 119595 )

Attachments

(2 files, 1 obsolete file)

The Static Analysis tool Coverity added cursor has memory leak in the following block code:

>>          if (cursor == null || !cursor.moveToFirst()) {
>>            notifyCursorDone(mRequestId);
>>            return;
>>          }

this could happen only if the second part of if evaluates to true. If so we should call cursor.close()
Summary: [Static Analysis][Resource leak] In Function createThreadCursor → [Static Analysis][Resource leak] In Function createThreadCursor::run
Comment on attachment 8718375 [details]
MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mcomella

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/34535/diff/1-2/
Comment on attachment 8718375 [details]
MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mcomella

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/34535/diff/2-3/
Attachment #8718375 - Attachment description: MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run. r?mfinkle → MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mfinkle
Summary: [Static Analysis][Resource leak] In Function createThreadCursor::run → [Static Analysis][Resource leak] In Function createThreadCursor::run and getThreadFromCursorAndNotify
Whiteboard: CID 119596 → CID 119596, CID 119595
I've updated the patch since same issue, cursor was out of context before closing it.
Comment on attachment 8718375 [details]
MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mcomella

Passing to Mike. He's a better reviewer for this.
Attachment #8718375 - Flags: review?(mark.finkle) → review?(michael.l.comella)
Comment on attachment 8718375 [details]
MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mcomella

https://reviewboard.mozilla.org/r/34535/#review31797

::: mobile/android/base/java/org/mozilla/gecko/GeckoSmsManager.java:1068
(Diff revision 3)
>      msgCursor = cr.query(kSmsContentUri,

We reassign the cursor here without closing the previous cursor – can you make sure that gets closed? It should be in a `try {} finally { Cursor.close(); }` style block.

::: mobile/android/base/java/org/mozilla/gecko/GeckoSmsManager.java:1082
(Diff revision 3)
> +    msgCursor.close();

As per the other comment, this should be in a `try { } finally { Cursor.close(); }` block. It might be easier to use two separate variables for the Cursors.

::: mobile/android/base/java/org/mozilla/gecko/GeckoSmsManager.java:1104
(Diff revision 3)
> +            if (cursor != null )

This should also be in a `finally` block but I'm not sure how feasible it is in this case.
Attachment #8718375 - Flags: review?(michael.l.comella)
Comment on attachment 8718375 [details]
MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mcomella

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/34535/diff/3-4/
Attachment #8718375 - Attachment description: MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mfinkle → MozReview Request: Bug 1247636 - close cursor before returning from createThreadCursor::run and getThreadFromCursorAndNotify. r?mcomella
Attachment #8718375 - Flags: review?(michael.l.comella)
Hello Michael i've updated the bug with your suggestions but regarding your 3rd comment:
> +            if (cursor != null )
I don;t think query returns any exceptions:
>>    public final @Nullable Cursor query(@NonNull Uri uri, @Nullable String[] projection,
>>            @Nullable String selection, @Nullable String[] selectionArgs,
>>            @Nullable String sortOrder) {
>>        return query(uri, projection, selection, selectionArgs, sortOrder, null);
>>    }
Assignee: bogdan.postelnicu → michael.l.comella
Attachment #8718375 - Attachment is obsolete: true
Attachment #8718375 - Flags: review?(michael.l.comella)
Comment on attachment 8722207 [details]
MozReview Request: Bug 1247636 - Close Cursors in GeckoSmsManager.getThreadFromCursorAndNotify. r=sebastian

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/35901/diff/1-2/
Attachment #8722207 - Attachment description: MozReview Request: Bug 1247636 - Close Cursors in GeckoSmsManager. r=sebastian → MozReview Request: Bug 1247636 - Close Cursors in GeckoSmsManager.getThreadFromCursorAndNotify. r=sebastian
I had some suspicions about the other Cursors in this bug so I filed bug 1250325.
See Also: → 1250325
And it looks like we're poised to remove the GeckoSmsManager code anyway. Dep on bug 1250325 to remove code, likely dupe.
Depends on: 1250325
Unassigning because it looks like we'll remove this eventually.
Assignee: michael.l.comella → nobody
GeckoSmsManager is gone.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: