Bug 13285

Summary:

Coverity fixes.

Product:

WebKit

Reporter:

Krzysztof Kowalczyk <kkowalczyk>

Component:

New Bugs

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

mrowe

Priority:

Version:

523.x (Safari 3)

Hardware:

OS:

OS X 10.4

Attachments:

Description	Flags
coverity patch 00	hyatt: review-
coverity patch 01	darin: review+
coverity patch 02	mrowe: review-
coverity patch 03	darin: review+
coverity patch 04	darin: review+
coverity patch 05	rwlbuis: review+
coverity patch 06	darin: review+
coverity patch 07	darin: review+
coverity patch 08	darin: review+
coverity patch 09	darin: review+
coverity patch 10	darin: review-
coverity patch 11	darin: review+

Krzysztof Kowalczyk

Reported 2007-04-04 21:07:21 PDT

Coverity is a static analysis tool for C/C++ code. I've ran coverity on webkit code and this bug contains patches for the issues it found. I created multiple patches (as opposed to one with all the fixes) because: a) each issue is independent from others b) they can be accepted/rejected independently Not all of the issues reported by coverity are bugs that have obvious repro scenario but they're still worth fixing for the same reason it's worth fixing compiler warnings: when running coverity in the future, there will be less noise in the output hence real bugs will stand out.

Attachments
coverity patch 00 (1.72 KB, patch) 2007-04-04 21:09 PDT, Krzysztof Kowalczyk	hyatt: review-	Details Formatted Diff Diff
coverity patch 01 (1.15 KB, patch) 2007-04-04 21:10 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 02 (1.03 KB, patch) 2007-04-04 21:10 PDT, Krzysztof Kowalczyk	mrowe: review-	Details Formatted Diff Diff
coverity patch 03 (1.39 KB, patch) 2007-04-04 21:11 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 04 (1.15 KB, patch) 2007-04-04 21:11 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 05 (1.18 KB, patch) 2007-04-04 21:11 PDT, Krzysztof Kowalczyk	rwlbuis: review+	Details Formatted Diff Diff
coverity patch 06 (1.36 KB, patch) 2007-04-04 21:12 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 07 (1.32 KB, patch) 2007-04-04 21:12 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 08 (1.33 KB, patch) 2007-04-04 21:12 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 09 (1.10 KB, patch) 2007-04-04 21:13 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
coverity patch 10 (1.07 KB, patch) 2007-04-04 21:13 PDT, Krzysztof Kowalczyk	darin: review-	Details Formatted Diff Diff
coverity patch 11 (1.17 KB, patch) 2007-04-04 21:13 PDT, Krzysztof Kowalczyk	darin: review+	Details Formatted Diff Diff
Show Obsolete (9) View All Add attachment proposed patch, testcase, etc.

Krzysztof Kowalczyk

Comment 1 2007-04-04 21:09:56 PDT

Created attachment 13956 [details] coverity patch 00

Krzysztof Kowalczyk

Comment 2 2007-04-04 21:10:24 PDT

Created attachment 13957 [details] coverity patch 01

Krzysztof Kowalczyk

Comment 3 2007-04-04 21:10:48 PDT

Created attachment 13958 [details] coverity patch 02

Krzysztof Kowalczyk

Comment 4 2007-04-04 21:11:08 PDT

Created attachment 13959 [details] coverity patch 03

Krzysztof Kowalczyk

Comment 5 2007-04-04 21:11:27 PDT

Created attachment 13960 [details] coverity patch 04

Krzysztof Kowalczyk

Comment 6 2007-04-04 21:11:50 PDT

Created attachment 13961 [details] coverity patch 05

Dave Hyatt

Comment 7 2007-04-04 21:12:00 PDT

Comment on attachment 13956 [details] coverity patch 00 This seems like it could cause an actual behavioral change. Without a test or a changelog, I have to minus this.

Krzysztof Kowalczyk

Comment 8 2007-04-04 21:12:11 PDT

Created attachment 13962 [details] coverity patch 06

Krzysztof Kowalczyk

Comment 9 2007-04-04 21:12:30 PDT

Created attachment 13963 [details] coverity patch 07

Dave Hyatt

Comment 10 2007-04-04 21:12:44 PDT

Please don't post a huge # of unrelated patches in the same bug. If these are separate issues they should be separate bugs.

Krzysztof Kowalczyk

Comment 11 2007-04-04 21:12:52 PDT

Created attachment 13964 [details] coverity patch 08

Krzysztof Kowalczyk

Comment 12 2007-04-04 21:13:12 PDT

Created attachment 13965 [details] coverity patch 09

Krzysztof Kowalczyk

Comment 13 2007-04-04 21:13:28 PDT

Created attachment 13966 [details] coverity patch 10

Krzysztof Kowalczyk

Comment 14 2007-04-04 21:13:48 PDT

Created attachment 13967 [details] coverity patch 11

Mark Rowe (bdash)

Comment 15 2007-04-04 21:45:12 PDT

Comment on attachment 13958 [details] coverity patch 02 This "fix" looks to address a non-existent problem. If data is NULL then newSize is set to 0 and newSize * d->itemSize will also be zero, so data will not be dereferenced.

Mark Rowe (bdash)

Comment 16 2007-04-04 21:49:47 PDT

Comment on attachment 13959 [details] coverity patch 03 Under what conditions will sourceRanges be NULL at the call to spliceSubstringsWithSeparators? A quick reading of the code suggests to me that pushSourceRange will always be called at least once, which will result in sourceRanges being initialized. When is this not the case?

Mark Rowe (bdash)

Comment 17 2007-04-04 21:55:07 PDT

Comment on attachment 13967 [details] coverity patch 11 How does *removing* a NULL-check improve things in this case? This looks incorrect to me.

Krzysztof Kowalczyk

Comment 18 2007-04-04 23:47:13 PDT

(In reply to comment #15) > (From update of attachment 13958 [details] [edit]) > This "fix" looks to address a non-existent problem. If data is NULL then > newSize is set to 0 and newSize * d->itemSize will also be zero, so data > will�not be dereferenced. Like I explained in the beginning, even if a given problem is flagged by coverity because it cannot prove that memcpy() won't reference the possibly NULL pointer, it's still worth fixing so that when running coverity in the future won't show the same issue over and over again. It's the same logic you apply when fixing compiler warnings even if you know that ultimately they're benign.

Krzysztof Kowalczyk

Comment 19 2007-04-04 23:52:52 PDT

(In reply to comment #16) > (From update of attachment 13959 [details] [edit]) > Under what conditions will sourceRanges be NULL at the call to > spliceSubstringsWithSeparators? A quick reading of the code suggests to me > that pushSourceRange will always be called at least once, which will result in > sourceRanges being initialized. When is this not the case? when UString matchString = regExpObj->performMatch(reg, source, startPosition, &matchIndex, &ovector); returns -1 and source.size() is 0. Can it really happen in practice? I don't know - the code is too complex for me to say either way with 100% certitude. Coverity seems to think it's possible and I can't prove it wrong.

Krzysztof Kowalczyk

Comment 20 2007-04-04 23:59:04 PDT

(In reply to comment #17) > (From update of attachment 13967 [details] [edit]) > How does *removing* a NULL-check improve things in this case? This looks > incorrect to me. Coverity complains because this NULL check is, effectively, a no-op. Coverity sees a check for info_ptr != NULL so it infers that the programmer thinks that info_ptr can be NULL. But then it sees that info_ptr is blindly dereferenced anyway. So either the NULL check is wrong or the function will crash anyway in which case removing the check makes no difference (the function will crash in a different place). This is not to say that adding more NULL checks wouldn't be a valid solution - it's just more invasive change and I was afraid of introducing changes in behaviour.

Darin Adler

Comment 21 2007-04-05 08:34:09 PDT

Comment on attachment 13963 [details] coverity patch 07 Just a test tool. If it wasn't I'd suggest reordering the buffer allocation code and the fopen rather than adding the free. But as it is, r=me.

Darin Adler

Comment 22 2007-04-05 08:37:45 PDT

Comment on attachment 13966 [details] coverity patch 10 One of the observers could call clear(), and thus m_image could be 0, so Coverity is wrong here.

Rob Buis

Comment 23 2007-04-05 13:16:32 PDT

Comment on attachment 13961 [details] coverity patch 05 Looks fine to me. I think a few lines above this one a similar code construct is there, not sure if you have a patch for that already, but the same fix should be applied AFAICS.

Krzysztof Kowalczyk

Comment 24 2007-04-05 15:51:35 PDT

Comment on attachment 13957 [details] coverity patch 01 landed in r20733

Krzysztof Kowalczyk

Comment 25 2007-04-05 15:55:44 PDT

Comment on attachment 13960 [details] coverity patch 04 landed in 20734

Krzysztof Kowalczyk

Comment 26 2007-04-05 16:00:04 PDT

Comment on attachment 13961 [details] coverity patch 05 landed in 20735

Krzysztof Kowalczyk

Comment 27 2007-04-05 16:02:41 PDT

Comment on attachment 13963 [details] coverity patch 07 landed in 20736

Krzysztof Kowalczyk

Comment 28 2007-04-05 16:07:20 PDT

Comment on attachment 13964 [details] coverity patch 08 landed in r20737

Krzysztof Kowalczyk

Comment 29 2007-04-05 16:10:20 PDT

Comment on attachment 13965 [details] coverity patch 09 landed in 20738

Darin Adler

Comment 30 2007-04-06 13:44:01 PDT

Comment on attachment 13959 [details] coverity patch 03 r=me

Krzysztof Kowalczyk

Comment 31 2007-04-06 20:19:44 PDT

Comment on attachment 13959 [details] coverity patch 03 landed in r20775

Krzysztof Kowalczyk

Comment 32 2007-04-06 20:23:08 PDT

Comment on attachment 13962 [details] coverity patch 06 landed in r20776

Krzysztof Kowalczyk

Comment 33 2007-04-06 20:25:31 PDT

Comment on attachment 13967 [details] coverity patch 11 landed in r20777

Note You need to log in before you can comment on or make changes to this bug.