crash possible because fSearchResults = nsImapSearchResultSequence::CreateSearchResultSequence() isn't null checked



11 years ago
4 years ago


(Reporter: mkmelin, Unassigned)




Firefox Tracking Flags

(Not tracked)





11 years ago
timeless in bug 341929 comment 3

problems i see:
  81 bienvenu 1.91    fSearchResults =
isn't null checked, so when it fails (oom can happen), it'll crash.


10 years ago
Product: Core → MailNews Core


9 years ago
Summary: fSearchResults = nsImapSearchResultSequence::CreateSearchResultSequence() isn't null checked → crash possible because fSearchResults = nsImapSearchResultSequence::CreateSearchResultSequence() isn't null checked
comment 0 still appears to be true

(checking vers=1.8/2.0 crash bugs)
Version: 1.8 Branch → Trunk
42 class nsImapSearchResultSequence : public nsVoidArray
44 public:
46     static nsImapSearchResultSequence *CreateSearchResultSequence();
53 private:
54     nsImapSearchResultSequence();
49 nsImapSearchResultSequence *nsImapSearchResultSequence::CreateSearchResultSequence()
50 {
51   return new nsImapSearchResultSequence;
52 }

So this is a "trivial" factory, isn't it?

    * line 83 -- fSearchResults = nsImapSearchResultSequence::CreateSearchResultSequence();
    * line 46 -- static nsImapSearchResultSequence *CreateSearchResultSequence();
    * line 49 -- nsImapSearchResultSequence *nsImapSearchResultSequence::CreateSearchResultSequence()

And, ftr, it's called in one place only.

"if new can not allocate memory on the heap it will throw an exception of type std::bad_alloc"
"Infallible memory allocation
Introduced in Gecko 2.0"

I'm not familiar with Gecko memory allocations (in trunk and branches).
Is a try+catch missing? (It doesn't seem to be the way Mozilla does it :-|)
Is this implicitly using a fallible allocator which can return null instead of throwing?

Comment 3

8 years ago
prior to mozilla2 our code was written using a design and compiler flags such that new returned null on failure instead of throwing an exception.

This enabled us to theoretically write applications which didn't abort when low on memory.

The tradeoff for this is that each place where we allocated memory we had to ensure we checked for failure. If we didn't check for failure, scary things could happen.

With mozilla2 we're trying to switch to the more "standard" behavior where new causes the app to die when you run out of memory. this is theoretically safer form a security perspective, but it does mean any data which is in an unhappy state or uncommitted state will be left that way (or lost).
(In reply to comment #3)

Thanks for the explanation/confirmation.


on 2.0, this would be WontFix or it should call the fallible allocator;
on 1.9.2/1.9.1, we could add a null-check(s) or leave it WontFix.

Comment 5

7 years ago
So is this still relevant?
(In reply to :aceman from comment #5)
> So is this still relevant?

magnus can you tell?  (if not please pass on to rkent or irving)
Assignee: mozilla → nobody
Flags: needinfo?(mkmelin+mozilla)

Comment 7

4 years ago
I don't know. Passing the question along
Flags: needinfo?(mkmelin+mozilla) → needinfo?(irving)
Looks to me like we're using the default allocator, so it should throw an exception when out of memory. We'd have to pass the OOM handling up through the nsImapServerResponseParser constructor, which I don't think is worth doing at this point.
Last Resolved: 4 years ago
Flags: needinfo?(irving)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.