Closed Bug 548102 Opened 15 years ago Closed 9 years ago

Crash Report [@ nsExpirationTracker<imgCacheEntry, 3u>::RemoveObject(imgCacheEntry*) ]

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: MatsPalmgren_bugz, Assigned: ma1)

Details

(Keywords: crash)

Crash Data

Attachments

(3 files, 2 obsolete files)

Development snapshot of HTTPS Everywhere with twitter AWS rule
109.96 KB, application/x-xpinstall
Details
Disable the nsIURI and nsIContentPolicy context.src modification codepaths.
109.99 KB, application/x-xpinstall
Details
"Early cancel & deferred redirect" hack leveraging AsyncAbort()
109.68 KB, application/x-xpinstall
Details
I have a reproduction case for this that is triggered by HTTPS-Everywhere. I can attach gdb to firefox and reliably cause this crash, but I'm not sure how to deal with unmarshalled XPCOM pointers in the backtrace to figure out what urls are being checked for expiry due to which exact redirect, and why. Are the right people CC'd on this new bug? I can also attach an .xpi that will cause this bug if anyone is actually paying attention to this stuff...
Great! Please attach the .xpi and give us the steps to reproduce. Also, which version of Firefox are you using?
Adjusting title to show up in recent Fennec crashes such as http://crash-stats.mozilla.com/report/index/51c47bbd-ef1d-49fc-8a18-3de482101027
Summary: Crash Report [@ nsExpirationTracker<imgCacheEntry, 3>::RemoveObject(imgCacheEntry*) ] → Crash Report [@ nsExpirationTracker<imgCacheEntry, 3u>::RemoveObject(imgCacheEntry*) ]
timeless - thanks, but that page still seems to have missing information. For example, the backtrace is filled with nsIURI interface pointers.. I'm not sure how to get the url strings out of these. The nsIURI type has a bunch of GetXXX() methods from the XPCOM marshalling from the IDL, but all of these take nsAutoString output parameters and similar things to be filled in, which I can't really just create to provide on the GDB stack.. I've tried dumping the raw bytes of the nsIURI pointer, but I'm guessing there's probably a level or two of indirection down to the actual strings. I suppose with effort I could dig through the marshalling code to figure the memory layout out... Unless there are better docs? At any rate, I'll attach an .xpi that provides a reliable repro shortly.
This attachment comes from the favicons branch at git repo: git://git.torproject.org/mikeperry/https-everywhere.git. The commit head is b0501028adb920d13b67c92f2a9455fc7c5a393f. There are three new commits there: commits to change and then disable a favicons check, and a special twitter rule to trigger the check.
Note that the check I altered to cause this repro is the same check used in NoScript, which was originally added to work around bug 480352. However, this workaround has false positives, and causes NoScript (and thus HTTPS-Everywhere, which is based on NoScript code) to block arbitrary images and prevent them from downloading and displaying, when the redirection+rewrite codepaths are exercised. The bug is triggered by spending about 3-5 minutes visiting random profiles on https://twitter.com. This triggers a new updated twitter rule, which causes TLS connections to be forced for more images, which triggers the bug. Try to visit image-heavy profiles. This quickly reproduces this crash on Firefox 3.6.12 on Linux, at least.
To investigate nsIURI pointers, try |print *ptr| after executing |set print object on|.
Thanks Josh. I guess that command was buried in the debugging doc... I've played around with this for a bit, and it looks like there may be some kind of race on gCacheTracker->MarkUsed() for a particular image in the image cache that is being redirected from http to https. The url in the cache is still the http url.. The crash is because RemoveObject() in the nsExpirationTracker sets the state to nsExpirationState::NOT_TRACKED. Then, the call to MarkUsed() calls RemoveObject() again, and when the state is already NOT_TRACKED, you get an empty generation array, which is then accessed via operator[] with a -1. Are there any tinderbox builds anywhere that have assertion symbols? If I could run one of those, I could get an assertion earlier, before the actual crash, which may give some more info. Unfortunately, the link Jesse refers to in http://www.squarefree.com/2010/01/14/downloadable-debug-builds/ no longer actually contains any debug builds available for download.
> the link Jesse refers to in [...] no longer > actually contains any debug builds available for download. Are you sure? The "mozilla-central-*-debug" folders appears to have builds.
Mats - I didn't try the mozilla-central builds for several reasons, one of which is that this is an addon-related crash bug triggered by NoScript and HTTPS Everywhere's use of nsITraceableChannel and channel replacement. If anything addon, channel, or cache related has changed in head, the repro might not be valid or possible. In fact, in FF4, I know the redirect codepaths got an extra callback that may interfere with this (asyncOnChannelRedirect). I can give it a shot anyway, I suppose, but it would be nice if we could get at least one set of stable, debug-enabled builds out there for issues like this. The way I read Jesse's post was that the whole reason why these (now empty) debug build directories were created was to allow easy reproduce of crashes on assert-enabled, yet stable Firefox versions. However, there do not appear to be any debug builds other than central, despite there being many many empty directories named *-debug.
I am having trouble reproducing this on the assert-enabled mozilla-central FF4b8 builds. Can't seem to get it to crash with the same .xpi. Tons of image-cache related asserts though. So maybe the crash is possibly limited to FF3.x? Are you still getting crash reporter submissions for FF4 for this backtrace?
Here's one for 4.0b8pre: http://crash-stats.mozilla.com/report/index/bf270020-245d-46ae-80c5-daba72101020 there are about 20 for 4.0b6. Please file separate bug(s) for the FF4 assertions (if needed). Mark them as blocking this bug.
I can reproduce the crash in my 1.9.2 debug build on x86-64 Linux. Just before the crash I get: ###!!! ASSERTION: Tried to remove an object that's not tracked: 'state->IsTracked()', file ../../../dist/include/nsExpirationTracker.h, line 149
OS: Windows XP → All
A few more assertions (on 1.9.2): ###!!! ASSERTION: attempt to modify an immutable nsStandardURL: 'Error', file netwerk/base/src/nsStandardURL.cpp, line 1136 ###!!! ABORT: Proxyless entry's request has cache entry!: '!request->HasCacheEntry()', file modules/libpr0n/src/imgLoader.cpp, line 1398 ###!!! ASSERTION: Unexpected request: 'request == mCachePump || request == mTransactionPump', file netwerk/protocol/http/src/nsHttpChannel.cpp, line 5170 for the last one I have: (gdb) p *request $4 = { <nsISupports> = { _vptr.nsISupports = 0x7fffe9ad6d48 }, <No data fields>} (gdb) x/aw 0x7fffe9ad6d48 0x7fffe9ad6d48 <_ZTV13nsHttpChannel+1272>: 0xffffffffe9a2c17b (gdb) p mCachePump $5 = { mRawPtr = 0x0 } (gdb) p mTransactionPump $6 = { mRawPtr = 0x0 } (gdb) p this $8 = (nsHttpChannel *) 0x7fffd564d000 (gdb) p request $9 = (nsHttpChannel *) 0x7fffd564d000
Uh, that last bit is _really_ broken. And looking at the code, it looks like this code is trying to call URI setters on a channel's URI. The fact that this ever works is a bug (we've wanted to make channel URIs immutable for years now), and when it does "work" it WILL break upstream consumers (like the image cache, here) and break them badly.
In particular, you're changing cache keys without giving the cache the chance to remove entries using the old key and add them using the new one, which is the proximate cause of this bug's crash.
Boris: Are you saying that HTTPS Everywhere should not be modifying URIs in HTTPS.js replaceURI()? Is that what you mean? Your antecedents are unclear. Right now, that code is attempted because it was our understanding (and apparently NoScript's too) that immutable nsIURI's would throw an exception during modification attempt. If we get an exception in that function, we fall back to either nsITraceableChannel channel replacement, or modification of the context.src attribute from nsIContentPolicy.shouldLoad(). To confirm this, I did a quick change to the code to skip the replaceURI codepath in HTTPS Everywhere. The crash still happens in 3.6.x when we do not modify nsIURIs.
For kicks, I tried removing the context.src modification in the nsiContentPolicy too, so we would then only be rewriting URIs using the nsITraceableChannel stuff, which should be modifying neither DOM nor nsIURIs. At least not directly... This still causes the same crash in the expiration tracker. I'll attach this new .xpi in the next update to this bug. It spits out some spurious warnings as a result of the hacked codepaths, but the crash still happens by browsing twitter with it installed.
This new .xpi should be disabling all direct nsIURI modification, as well as nsIContentPolicy context.src modification. The git commit hash is e36be61c0d8d2e13dfe3ee7619b996c344deca73 in branch favicons in my public remote at git://git.torproject.org/mikeperry/https-everywhere.git if you would like to see the git diffs for this change.
> Boris: Are you saying that HTTPS Everywhere should not be modifying URIs in > HTTPS.js replaceURI()? That's correct. > immutable nsIURI's would throw an exception during modification attempt. They do. Channel URIs are unfortunately not set immutable at the moment. They really should be, though. (In fact, imo all URI objects in Gecko should be immutable, since you never know when someone else has the same URI object and is using it for something else.... but that's a separate story.) > we fall back to either nsITraceableChannel channel replacement, or > modification of the context.src attribute from nsIContentPolicy.shouldLoad(). Ah. Indeed. I just looked at that channel-replacement code. That's going to violate the nsIChannel contract, and it's quite conceivable that consumers might break with it. In particular, it will send two sets of start/stop notifications, for different URIs, to the listener. And it's passing the channel as the request to itself; so the first and third asserts in comment 15 are definitely on that codepath...
Boris: Are you saying (In reply to comment #21) > > we fall back to either nsITraceableChannel channel replacement, or > > modification of the context.src attribute from nsIContentPolicy.shouldLoad(). > > Ah. Indeed. I just looked at that channel-replacement code. That's going to > violate the nsIChannel contract, and it's quite conceivable that consumers > might break with it. In particular, it will send two sets of start/stop > notifications, for different URIs, to the listener. And it's passing the > channel as the request to itself; so the first and third asserts in comment 15 > are definitely on that codepath... Is there a correct way to do this then? I'm not the original author of this code (I believe it is Giorgio's.. He's CCed, not sure if he's listening), but it looks like its trying to simulate a regular 302 redirect using channel replacement. I see cancel events to tell listeners that there was a redirect. I can see how the original listener will get two sets of start and stop events, since it is transferred from the old channel to the new channel, but shouldn't this also happen for a regular redirect? Are you saying that the event sequence is not the same as a true redirect, and that this may be causing problems in the image cache? Channels are nsIRequests, so passing them in to the stop events should be OK, right? Or is this also somehow wrong?
> Is there a correct way to do this then? You could replace the observer on the old channel with something that will just ignore notifications and then set its old observer on the new channel. And you'd need to make sure to send OnChannelRedirect notifications... > but shouldn't this also happen for a regular redirect? For a regular redirect, the pre-redirect channel knows it was redirected (sine it made that decision itself), and doesn't deliver the notifications. > Are you saying that the event sequence is not the same as a true redirect Yes. > so passing them in to the stop events should be OK It's "ok" in the sense that as C++ it would compile, but that particular request observer implementation expects only particular requests to come through (the ones it handed itself to as a request observer!) and conditions behavior on what arguments it sees. So if an unexpected request is passed in, one of the two branches will be taken, but behavior will then be wrong. Or put another way, just because an object QIs to some interface doesn't mean that passing arbitrary arguments to methods of the result is expected or leads to sensible behavior.
(In reply to comment #23) > > Is there a correct way to do this then? > > You could replace the observer on the old channel with something that will just > ignore notifications and then set its old observer on the new channel. > > And you'd need to make sure to send OnChannelRedirect notifications... Perhaps I'm confused, but it looks to me like the listener disabling code is in CtxCapturingListener() and the onChannelRedirect notifications are sent in replace(). > It's "ok" in the sense that as C++ it would compile, but that particular > request observer implementation expects only particular requests to come > through (the ones it handed itself to as a request observer!) and conditions > behavior on what arguments it sees. So if an unexpected request is passed in, > one of the two branches will be taken, but behavior will then be wrong. > > Or put another way, just because an object QIs to some interface doesn't mean > that passing arbitrary arguments to methods of the result is expected or leads > to sensible behavior. Is it possible to get back to the proper requests to pass in here? > For a regular redirect, the pre-redirect channel knows it was redirected (sine > it made that decision itself), and doesn't deliver the notifications. In general, can you point me to the portions of the Mozilla source you are referring to for this? Again, this isn't my code, so I'm just trying to guess what Giorgio was thinking, and I don't have the knowledge of the original channel redirect architecture and handlers to catch exactly what Mozilla source files and lines you are referring to here. Also, are we certain that these bugs in this channel redirection are causing the crashes? Or might they just be causing other problems?
Ah, CtxCapturingListener might do the right thing, yes. And yes, _onChannelRedirect seems to be doing the right thing at first glance... > Is it possible to get back to the proper requests to pass in here? Sadly, no. :( > can you point me to the portions of the Mozilla source you are > referring to for this? I think nsHttpChannel::SetupReplacementChannel is the relevant thing here. > Also, are we certain that these bugs in this channel redirection are causing > the crashes? Certain, no. However imgRequest::OnChannelRedirect removes from cache for the old URI and readds for the new one, so if the http URI is still in the cache that sounds like it was never called.... I'll try installing that last extension and trying to reproduce this locally, I guess, but not at 2am. ;)
On a side note, could we get a sensible and "safe" API (on nsIHttpChannel, perhaps) to cause internal redirections (channel replacements) which happen before the request is sent? As you can see, I had to implement incredible hacks to obtain this effect, but I believe I did not have any other option (I already asked for something like this in the CSRF. This is even more needed since I'm scrubbing all my code for nsIURL modifications and turning them into channel replacements, in order to avoid the "changed cache key" issue which, IMHO, is the most likely culprit for this crash.
> could we get a sensible and "safe" API Would be nice; worth a separate bug. ;) So if I install that last extension and load: data:text/html,<img src="http://web.mit.edu/img/BackImage.jpg"> should I expect to see an https load or an http one?
Boris: The extension is rule based, and there is no MIT rule. Also, the bug is non-deterministic. The best way to trigger it is to navigate around twitter for a while with gdb attached.
I can reproduce the _crash_ part just fine if I need to; that's not a problem. What I need is a simple testcase of an image the extension will mess with, so I can examine exactly what imagelib sees for that one image. What's a url to such an image?
Boris, http://www.mozilla.com/img/tignish/home/feature-logo.png should be an example of such a redirected image.
Perfect, thanks. So yes, this is a bug in the extension. Necko is _async_. In particular, the assumption is that there will be no reentry into the caller under an AsyncOpen() call; all notifications are delivered asynchronously. This is, perhaps, not documented as well as it should be.... Imagelib has code like this: nsresult openRes = newChannel->AsyncOpen(static_cast<nsIStreamListener *>(pl), nsnull); // check openRes, bail out if failed PutIntoCache(aURI, entry); But the attached extension dispatches a OnChannelRedirect to the imgRequest before AsyncOpen returns. Normally, an imgRequest that's in the cache will update the URI it's cached under when it gets OnChannelRedirect. But since the notification is being dispatched at a time when necko promises no notifications relevant to newChannel, the imgRequest is not in the cache yet, and has nothing to update. Then it's inserted into the cache, but with the wrong URI. The right fix for this is to make sure to spin up the new channel asynchronously, not directly under the HTTP observer notification. Joe, I suppose we could work around this in imagelib by getting the URI to pass to PutIntoCache from the imgRequest instead of assuming aURI is still the right thing... that might at least reduce the incidence of this crash for our users, pending whatever extensions are using this code being fixed. But there might well be other correctness side effects, including in other consumers, from this API violation. So the extensions definitely need to be fixed.
(In reply to comment #31) > But the attached extension dispatches a OnChannelRedirect to the imgRequest > before AsyncOpen returns. The fake redirection is actually emulated during an loadGroup->addRequest() call, i.e. at the latest time which I could find when the channel initialization flow could be intercepted before the request hits the net. When I found that image channels were unhappy with this setup, I worked around in NoScript by early suppressing/redirecting image requests at the nsIContentPolicy::shouldLoad() stage (when cache is not an issue yet). HTTPSEverywhere removed part of this work-around, hence the crash (which doesn't seem to affect NoScript, indeed). > The right fix for this is to make sure to spin up the new channel > asynchronously, not directly under the HTTP observer notification. Would using nsIHttpChannel::suspend() from the loadGroup callback (where we currently start the redirection) and deferring the actual redirection setup help, still preventing the request from hitting the net? If that doesn't work or is still unsafe, we definitely need an "http-on-before-send" notification to be sent by nsIHttpChannel::Connect() (or even better, as soon as DNS resolution is done if needed), like the one I was already asking here: https://bugzilla.mozilla.org/show_bug.cgi?id=354493#c88
I did check, and suspend() doesn't work, because at the time it's called the transaction has not been setup yet, and by the time suspendcount is checked first and the transaction suspended, the request has been already sent :( However I've quickly tried another hack, which seems to work even though I couldn't check yet whether it has even worse side effects: rather than using channel.suspend(), I'm now using channel.cancel(NS_OK). This causes AsyncOpen() to return NS_OK without calling Connect(). Then dispatch for later execution a runnable which asynchronously performs the redirection. As I said, so far it appears to work. Boris, is this hack doomed to fail as well?
Errata corrige: once the request is pending (during addRequest(), when we do it), no matter which code with Cancel() with AsyncOpen() will return NS_OK (as noted by myself in the comments of ChannelReplacement.replace()). So, more correctly even if still hackish, we can use channel.cancel(NS_BINDING_REDIRECTED). The difference with a "true" redirection is that we do it early, before sending out onChannelRedirect() notifications.
This implements the "early cancel and deferred redirection" hack which should trick image channels into behaving correctly with their cache. In IOUtil.js the ChannelReplacement.replace() method has been split and made asynchronous: 1) it ensures the channel is in pending state (otherwise the nsITraceableChannel hack won't work) 2) as soon as it's pending, it cancels the channel with NS_BINDING_REDIRECTED status (since the channel is already in asynchronous notifications mode, asyncOpen() will return NS_OK anyway) 3) A runnable is posted in the event queue, in order to defer the actual redirection machinery. Boris, could you confirm it doesn't crash anymore for you? Can you see any non-theoretical new problem caused by this change?
This version just anticipates the asynchronous redirection by pushing a dedicated event queue and posting it there, then restoring the regular event queue when done with the redirection (Thread.basap() instead of Thread.asap()). This change should minimize the side effects of the early cancel, by guaranteeing the redirection to happen in the very next event. Still a hack, but with it I couldn't observe any new issue so far (I'm using a NoScript build which uses this hack on any request whose DNS records have not been cached yet).
Attachment #488675 - Attachment is obsolete: true
(In reply to comment #31) > Joe, I suppose we could work around this in imagelib by getting the URI to pass > to PutIntoCache from the imgRequest instead of assuming aURI is still the right > thing... that might at least reduce the incidence of this crash for our users, > pending whatever extensions are using this code being fixed. This seems OK at first glance, but I'm a bit worried about correctness wrt redirects, remembering how many times we had to fix that, and in different ways. I'll have to think on it a while.
Giorgio: Just to confirm, the content policy workaround you're referring to that we removed was the image request header check combined with the PolicyState.extract() content policy load test, right? We removed that in this test .xpi because we saw false positives for it that appeared to be blocking random images, and then we noticed the increased crash rate and found this bug. The interesting thing is that afaik, we never released that code with the workaround disabled into the wild, so the crash reports that Mozilla has seen from this bug came through either that workaround failing, or some other issue.. We have also heard anecdotal crash reports from our users who should have had the workaround present, but were not able to reproduce it ourselves until we removed the workaround.
> The fake redirection is actually emulated during an loadGroup->addRequest() Which is before asyncOpen returns. > Would using nsIHttpChannel::suspend() from the loadGroup callback (where we > currently start the redirection) and deferring the actual redirection setup > help, still preventing the request from hitting the net? I don't know. Why not do the "cancel the old channel" part of the redirection as you do now, but not dispatch the redirect callback or set up the new channel until the event loop has spun? > "http-on-before-send" notification Might be a good idea, if things are on the right threads at that point. File a bug? > I'm now using channel.cancel(NS_OK) Please, no. The nsIRequest IDL makes it clear that this should not be done unless you know for a fact that the nsIRequest you have allows it. As it happens, HTTP channels do not; this will cancel the cache and network pumps with NS_OK, and streampump relies on Cancel() setting mStatus to an error code for correct functioning. > we can use channel.cancel(NS_BINDING_REDIRECTED) Yeah, that's more like it. > The difference with a "true" redirection is that we do it early, before > sending out onChannelRedirect() notifications. "True" redirections have to deal with the redirection being denied, in which case the load of the old channel should proceed. However in your case if the redirection is denied you want to fail the load compeletely, so canceling the old channel first (after setting up your own streamlistener on it, of course) is not a problem. > Boris, could you confirm it doesn't crash anymore for you? Yes (though there's still the bogosity of calling OnStartRequest on channels with bogus request arguments, which is asserting of course).
(In reply to comment #38) > Giorgio: Just to confirm, the content policy workaround you're referring to > that we removed was the image request header check combined with the > PolicyState.extract() content policy load test, right? Yes it is. The interesting thing is that afaik, we never released > that code with the workaround disabled into the wild, so the crash reports that > Mozilla has seen from this bug came through either that workaround failing, or > some other issue.. I suspect they might be due to CSS-triggered image loads... (In reply to comment #39) > > The fake redirection is actually emulated during an loadGroup->addRequest() > > Which is before asyncOpen returns. Indeed. I was just stating I had no other choice. > Why not do the "cancel the old channel" part of the redirection > as you do now, but not dispatch the redirect callback or set up the new channel > until the event loop has spun? > In fact that's what my patched HTTPS Everywhere version and currently shipping NoScript dev builds are doing. > > we can use channel.cancel(NS_BINDING_REDIRECTED) > > Yeah, that's more like it. That's what I finally choose, in fact, counting on clients not checking the status immediately after asyncOpen(), since they had NS_OK as the return code (or, for JS clients, asyncOpen() didn't throw). > Yes (though there's still the bogosity of calling OnStartRequest on channels > with bogus request arguments, which is asserting of course). Is there any way you can suggest to avoid that while properly notifying the right listeners? Can you see any real practical problem with the current setup? Thanks.
> Is there any way you can suggest to avoid that Why do you need that call at all? What happens if you take it out?
(In reply to comment #41) > > Is there any way you can suggest to avoid that > > Why do you need that call at all? What happens if you take it out? I need it to capture the original request context, by tricking the channel into calling into my CtxCaptureListener methods. If I take it out I cannot fake the redirection because I miss the original context to pass to the new replacement channel.
> by tricking the channel into calling into my CtxCaptureListener methods. Does the channel not call OnStartRequest on its listener if you don't do this? If so, seems like that's a bug in the channel, no?
(In reply to comment #43) > > by tricking the channel into calling into my CtxCaptureListener methods. > > Does the channel not call OnStartRequest on its listener if you don't do this? > If so, seems like that's a bug in the channel, no? Where should the channel call me if I cancel it during AsyncOpen(), and therefore it never hits Connect() (which is what I do want, because I must prevent network activity)?
If you look at nsHttpChannel::AsyncOpen, if mCanceled is true _and_ mStatus is an error after AddRequest (this is where canceling with an error code matters!) then we will call AsyncAbort. And AsyncAbort posts an event to notify the channel's listener. So if you cancel with an error code during AddRequest, after setting a new listener on the channel, and then wait until that listener gets an OnStartRequest, you will get the context at that point.
OK, then now that I perform the fake redirect AFTER cancelling the channel, I can safely drop the forced onStartRequest() stuff, it seems. Of course that call was needed when I used to cancel at the "orthodox" time, i.e. after the redirection, because I needed the context before anybody had called the listener yet. Thanks for the hint. Let me try this in NoScript and post an updated HTTPS Everywhere version.
Per Boris' suggestion, this version leverages the fact nsHttpChannel::AsyncOpen() will call AsyncAbort() if canceled early with an error status code. This allows for interesting simplifications in the code: rather than explicitly spinning the event loop (or pushing a dedicated one) and forcing a "bogus" nsHttpChannel::OnStartRequest() to be called back, we rely instead on AsyncAbort() calling back our CtxCapturingListener.onStartRequest() after AsyncOpen() has returned, triggering our fake redirection directly there.
Attachment #488726 - Attachment is obsolete: true
Assignee: nobody → g.maone
FYI: We're getting reports that the new 0.3.0 HTTPS Everywhere development release is causing 100% cpu usage on Mac OS after some arbitrary amount of activity. It doesn't seem to be happening on other platforms. We used the NoScript 2.0.5.1 version of the channel replacement code. We are still trying to get ahold of a Mac user with gdb installed, so we can try to get a DumpJSStack backtrace while the CPU is pegged.
Please notice that IOUtils.js in 2.0.6 dev builds fixes an issue with requests which have already been aborted before they're added to the load group being replaced anyway. Not sure whether this is related, though.
On a side note, the new method for faking internal redirections seems to be breaking Flash on latest trunk, see http://forums.informaction.com/viewtopic.php?f=7&t=5394 :(
Hmm. Mail me an HTTP log (as small as you can make it) that shows the problem? That's really outside the scope of this bug as a core bug....
Crash Signature: [@ nsExpirationTracker<imgCacheEntry, 3u>::RemoveObject(imgCacheEntry*) ]
Does this still crash the latest Nightly?
Teo, anyone can query stack signatures at https://crash-stats.mozilla.com/query The latest build ID I can find is 20110726030825 (Firefox 8.0a1) bp-f7410433-29f5-4303-bfed-46ad62110727 which points to bug 628622. I don't know if it's related.
Crash Signature: [@ nsExpirationTracker<imgCacheEntry, 3u>::RemoveObject(imgCacheEntry*) ] → [@ nsExpirationTracker<imgCacheEntry, 3u>::RemoveObject(imgCacheEntry*) ] [@ nsExpirationTracker<T>::RemoveObject ]
Fixed long ago, forgot to close the bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: