536792 - trunk topcrash [@ memcpy | nsFastLoadFileReader::Read(char*, unsigned int, unsigned int*)]

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

There are a decent number of crash reports on trunk at
memcpy | nsFastLoadFileReader::Read(char*, unsigned int, unsigned int*)

http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=memcpy%20|%20nsFastLoadFileReader%3A%3ARead%28char*%2C%20unsigned%20int%2C%20unsigned%20int*%29&version=Firefox%3A3.7a1pre

They seem to have spiked around December 15-17, but they've been persistent at somewhat lower levels than that spike for a while.

Some of the comments are interesting, e.g.:

This and previous crashes may be do to the lack of the various extensions.* files in the profile having been deleted. Rather than just proceeding to recreate these files, Minefield has been crashing on the first try. Previously, the browser just handles this.

crashed at startup

Comment 1

[Brendan Eich [:brendan]]

Is this due to the removal of file mtime checking in the patch for bug 531886 ?

/be

Comment 2

[Benjamin Smedberg]

No, almost certainly not. It appears to be a case where we write the fastload file after reading it (e.g. for loading some new module) in which case the offset is valid but the mmap has been closed. Taras is on it.

Comment 3

[Brendan Eich [:brendan]]

Is this bug getting the patch? The other bug's patch doesn't address the update logic.

/be

Comment 4

[(dormant account)]

(In reply to comment #3)
> Is this bug getting the patch? The other bug's patch doesn't address the update
> logic.
> 

The crash backtrace looks like we may have a Close()ed fastload stream that someone is Read()ing from. The patch in 537158 guards against that. I'm not sure what lead to that situation. Before mmap change the file descriptor would just fail a read() instead of segfaulting.

Comment 5

[Wayne Mery (:wsmwk)]

this is also a topcrash for (what was) Thunderbird 3.1a1pre
example bp-c458d9a9-c925-4c48-bb74-5c3c72091220

Comment 6

[(dormant account)]

I haven't seen any more crashes since the landing of bug 537158. Is it ok to close this?

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.7a1pre&query_search=signature&query_type=exact&query=memcpy%20|%20nsFastLoadFileReader%3A%3ARead%28char*%2C%20unsigned%20int%2C%20unsigned%20int*%29&date=&range_value=31&range_unit=days&do_query=1&signature=memcpy%20|%20nsFastLoadFileReader%3A%3ARead%28char*%2C%20unsigned%20int%2C%20unsigned%20int*%29
agrees that almost all of the crashes stopped after the 2009123100 build (see the "Table" tab).  So yes, I think it's ok to close this.  Doing so.

(There was one newer crash, bp-c73e07f9-f6ad-4f35-8a73-348e82100106, but I don't think that needs to hold this bug open.)

Comment 8

[Wayne Mery (:wsmwk)]

sounds OK from Thunderbird trunk perspective - no crashes since 20091219031754

Comment 9

[(dormant account)]

(In reply to comment #7)

> (There was one newer crash, bp-c73e07f9-f6ad-4f35-8a73-348e82100106, but I
> don't think that needs to hold this bug open.)

This one doesn't count, it's on the electrolysis branch which didn't contain my fix.