116311 - page-loader test crashes with new profile

Status: RESOLVED DUPLICATE of bug 117153

(Core :: XPCOM, defect)

Description

[kill this account]

when I create a new profile and run the page loader tests moz
crashes. I suspect this is a cache issue since it does not seem to happen
when I restart moz. I also believe I have seen this when I cleared cache.

Comment 1

[Boris Zbarsky [:bzbarsky]]

any chance of a stack?  What build is this?

Comment 2

[kill this account]

Attachment: purify FMR info

build 2001-12-20
FMR during display of http://www.mozilla.org/start

Comment 3

[kill this account]

sorry I did not see see a core file

Comment 4

[kill this account]

Attachment: another purify FMR and FMW

things seem to get really ill after this. Lots of error happen

Comment 5

[kill this account]

Attachment: purify log file (*.pv)

Comment 6

[Asa Dotzler [:asa]]

->cache

Comment 7

[gordon]

I see no evidence connecting this bug with the cache.  However, the free memory
read data should be looked into.

Comment 8

[Asa Dotzler [:asa]]

Does talkback (in a nightly build) catch this crash? 

Comment 9

[John Morrison]

To answer Asa's question: it probably does show up in a talkback log, but the 
stack in that case wouldn't mean much, since it is just a victim of the 
corruption. 

Thanks to bstell for getting those Solaris purify logs.

This is the crash that has been happening since Nov 27 IIRC in the pageloader 
tests on btek. It does seem to only happen on the initial, clean cache run of 
the test, which doesn't necessarily make it the cache, but the different code 
path would appear to expose this corruption. 

Coincidentally, dbaron modified nsSharedBufferHandle on Nov 27, which is 
implicated in the second set of purify logs attached.

Comment 10

[John Morrison]

*** Bug 114281 has been marked as a duplicate of this bug. ***

Comment 11

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

It would be more likely to be the modifications I made that caused string
sharing to be used in a few places.

Could this be bug 112547?  Or is it something simpler?

Comment 12

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

->String

Comment 13

[Brendan Eich [:brendan]]

scc is on sabbatical -- who can help?  jag?  dbaron?

/be

Comment 14

[Christopher Blizzard (:blizzard)]

The stack traces that are in bug 114281 are exactly like the ones that I'm
seeing on my machine at home.  I'm not just seeing it in the page load tests,
either.  I'm seeing it in mail, mostly since that's what I use most of the time.

I have a dual CPU machine which may make things worse.  What is btek?

There's a possibility that this isn't strings, it's just that this shows up with
strings since there's where most of our allocation happens and is first to
stumble over the bug.

It would be really great if we could find a way to reproduce this easily.

Comment 15

[Chris Waterson]

btek is a dual-CPU machine, too.

Comment 16

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

My machine is also dual-CPU, and I don't see it.

Comment 17

[Christopher Blizzard (:blizzard)]

dbaron, what compiler and linux install (assuming you're using linux?)

Comment 18

[Christopher Blizzard (:blizzard)]

I'm starting to think that the PAC bug that I filed (bug 116311) is the same as
this.

I know that one of the problems with the PAC patch is that when it's loaded it
loads the plugin host, the RDF code and some charset code from a non-main
thread.  This causes all kinds of assertions.  I've added thread safety to those
classes that were asserting about being called from the wrong thread but this is
just spackling over the real problem.

Comment 19

[Christopher Blizzard (:blizzard)]

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=mozilla%2F&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F25%2F2001+19%3A00%3A00&maxdate=11%2F28%2F2001+09%3A00%3A00&cvsroot=%2Fcvsroot

This bug appeared somewhere in this set of checkins.  dbaron, there are shared
string changes in there.

I had to binary search for the bad build.  Now I have to binary search the
checkins.  Weeeee!!!

Comment 20

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

> dbaron, what compiler and linux install (assuming you're using linux?)

gcc 3.0.2 with -O2 and RH 7.2

Comment 21

[Christopher Blizzard (:blizzard)]

Sorry, the PAC bug is bug 117153.  I've got that crash down to a single checkin
by dbaron.  I'll bet this bug is the same.

The PAC bug is relatively easy to reproduce, which is nice.

Comment 22

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

Hopefully this is fixed now, although it hasn't shown up as a problem on
tinderbox for at least a day or so anyway.

Comment 23

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

I'm going to dupe this since what I fixed matches bstell's purify log exactly

*** This bug has been marked as a duplicate of 117153 ***