Crash happened when switch Cobalt js engine to V8 - v8

To preview on Cobalt master(16.154703), everything works well with mosjs-45.
But when we switch engine to V8, a crash occurred
v8::internal::Factory::NewFixedArray() [0x8693f0]
v8::internal::TemplateList::New() [0x93bcec]
v8::internal::Heap::CreateApiObjects() [0xd6ad40]
v8::internal::Heap::CreateHeapObjects() [0xd6cc7c]
v8::internal::Isolate::Init() [0x909164]
v8::SnapshotCreator::SnapshotCreator() [0x70dbac]
v8::V8::CreateSnapshotDataBlob() [0x73c8b8]
cobalt::script::v8c::IsolateFellowship::InitializeStartupData() [0x70a58c]
cobalt::script::v8c::IsolateFellowship::IsolateFellowship() [0x70ad1c
cobalt::script::v8c::V8cEngine::V8cEngine() [0x6fa494]
cobalt::script::JavaScriptEngine::CreateEngine() [0x6fa63c]
cobalt::browser::WebModule::Impl::Impl() [0xbd4bc]
cobalt::browser::WebModule::Initialize() [0xbef4c]
(anonymous namespace)::RunAndSignal() [0xe4914]
MessageLoop::RunTask() [0xe50bc]
MessageLoop::DeferOrRunPendingTask() [0xe5b5c]
MessageLoop::DoWork() [0xe7b54]
base::MessagePumpDefault::Run() [0xe9428]
base::RunLoop::Run() [0xf2d10]
MessageLoop::Run() [0xe4a00]
It seems HandleScope has not been created, and the address 0x1 of
'isolate->handle_scope_data()->next' leads to this crash. I am not sure whether this issue is specific, please help us on this.

Can you please test against the latest Cobalt 16.162639 and report the issue to the Issue Tracker?
https://cobalt.googlesource.com/cobalt/+/b626c97d51f3afb82cce662b06c25b10a7d897d5
https://issuetracker.google.com/issues?q=componentid:181120

Related

azure stageBlock onProgress event

I'm using the stageBlock method and the onProgress callback. I thought I had this working when I wrote this 9 months ago but I'm doubting myself now. The progress update is showing "loadedBytes" and it does not resemble what is actually going over the network. onProgress reports as all bytes "loaded" while the browser is still uploading the file via a network request. How do you monitor the network bytes while using this azure method?
await blockBlobClient.stageBlock(blockId, chunk, chunk.size, {
onProgress: e => {
console.log('onProgress loadedBytes: ' + e.loadedBytes);
},
abortSignal: abortControllerRef.current.signal,
});
I'm using version 12.1.1 of azure nodejs package...
I have just upgraded to version 12.3.0 and still have the same problem.
Edit
I have created a small repro here: https://github.com/philwindsor/az-progress-bug
Its a react app, clone it and run yarn install then yarn run.
Gif of problem:
I ended up raising an issue on github: https://github.com/Azure/azure-sdk-for-js/issues/13161 which I have now closed.
Turns out our company virus scanner (sohpos) is the cause of the problem. Once disabled the problem goes away!

How to fix 'Unchecked runtime.lastError: The message port closed before a response was received' chrome issue?

Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I'm using VueJS and Laravel for my project. This issue started to show lately and it shows even in the old git branches.
This error only shows in the Chrome browser.
I disabled all installed extensions in Chrome - works for me.
I have now clear console without errors.
In case you're an extension developer who googled your way here trying to stop causing this error:
The issue isn't CORB (as another answer here states) as blocked CORs manifest as warnings like -
Cross-Origin Read Blocking (CORB) blocked cross-origin response
https://www.example.com/example.html with MIME type text/html. See
https://www.chromestatus.com/feature/5629709824032768 for more
details.
The issue is most likely a mishandled async response to runtime.sendMessage. As MDN says:
To send an asynchronous response, there are two options:
return true from the event listener. This keeps the sendResponse
function valid after the listener returns, so you can call it later.
return a Promise from the event listener, and resolve
when you have the response (or reject it in case of an error).
When you send an async response but fail to use either of these mechanisms, the supplied sendResponse argument to sendMessage goes out of scope and the result is exactly as the error message says: your message port (the message-passing apparatus) is closed before the response was received.
Webextension-polyfill authors have already written about it in June 2018.
So bottom line, if you see your extension causing these errors - inspect closely all your onMessage listeners. Some of them probably need to start returning promises (marking them as async should be enough). [Thanks #vdegenne]
If you go to chrome://extensions/, you can just toggle each extension one at a time and see which one is actually triggering the issue.
Once you toggle the extension off, refresh the page where you are seeing the error and wiggle the mouse around, or click. Mouse actions are the things that are throwing errors.
So I was able to pinpoint which extension was actually causing the issue and disable it.
Post is rather old and not closely related to Chrome extensions development, but let it be here.
I had same problem when responding on message in callback. The solution is to return true in background message listener.
Here is simple example of background.js. It responses to any message from popup.js.
chrome.runtime.onMessage.addListener(function(rq, sender, sendResponse) {
// setTimeout to simulate any callback (even from storage.sync)
setTimeout(function() {
sendResponse({status: true});
}, 1);
// return true; // uncomment this line to fix error
});
Here is popup.js, which sends message on popup. You'll get exceptions until you un-comment "return true" line in background.js file.
document.addEventListener("DOMContentLoaded", () => {
chrome.extension.sendMessage({action: "ping"}, function(resp) {
console.log(JSON.stringify(resp));
});
});
manifest.json, just in case :) Pay attention on alarm permissions section!
{
"name": "TestMessages",
"version": "0.1.0",
"manifest_version": 2,
"browser_action": {
"default_popup": "src/popup.html"
},
"background": {
"scripts": ["src/background.js"],
"persistent": false
},
"permissions": [
"alarms"
]
}
To me i was using a VPN extension called
Free VPN for Chrome - VPN Proxy VeePN It was causing the error after disabling it only ... the error disappeared
This error is generally caused by one of your Chrome extensions.
I recommend installing this One-Click Extension Disabler, I use it with the keyboard shortcut COMMAND (⌘) + SHIFT (⇧) + D — to quickly disable/enable all my extensions.
Once the extensions are disabled this error message should go away.
Peace! ✌️
If error reason is extension use incognito Ctrl+Shift+N. In incognito mode Chrome does not have extensions.
UPD. If you need some extension in incognito mode e.g. ReduxDevTools or any other, in extension settings turn on "Allow in incognito"
Make sure you are using the correct syntax.
We should use the sendMessage() method after listening it.
Here is a simple example of contentScript.js It sendRequest to app.js.
contentScript.js
chrome.extension.sendRequest({
title: 'giveSomeTitle', params: paramsToSend
}, function(result) {
// Do Some action
});
app.js
chrome.extension.onRequest.addListener( function(message, sender,
sendResponse) {
if(message.title === 'giveSomeTitle'){
// Do some action with message.params
sendResponse(true);
}
});
For those coming here to debug this error in Chrome 73, one possibility is because Chrome 73 onwards disallows cross-origin requests in content scripts.
More reading:
https://www.chromestatus.com/feature/5629709824032768
https://www.chromium.org/Home/chromium-security/extension-content-script-fetches
This affects many Chrome extension authors, who now need to scramble to fix the extensions because Chrome thinks "Our data shows that most extensions will not be affected by this change."
(it has nothing to do with your app code)
UPDATE: I fixed the CORs issue but I still see this error. I suspect it is Chrome's fault here.
In my case it was a breakpoint set in my own page source. If I removed or disabled the breakpoint then the error would clear up.
The breakpoint was in a moderately complex chunk of rendering code. Other breakpoints in different parts of the page had no such effect. I was not able to work out a simple test case that always trigger this error.
I suggest you first disable all the extensions then one by one enable them until you find the one that has caused the issue in my case Natural Reader Text to Speech was causing this error so I disabled it. nothing to do with Cross-Origin Read Blocking (CORB) unless the error mention Cross-Origin then further up the tread it is worthwhile trying that approach.
I faced the same error in my react project running.
That error coming from my chrome
IObit Surfing Protection
2.2.7
extensions. That extension off my error was solved.
If you face same like that error, 1st turn off your chrome ad blocker or any other extensions while running.
Late here but in my case it was Kaspersky Cloud Protection Extension. I disabled it. It worked all good.
The cause of this issue is related to one of your chrome extensions, not CORS or CORB. To fix that you can turn off each and every chrome extension you installed.
Norton Safe Web extension for chrome is throwing this error message for me. After I disabled this extension, the error message disappeared.
Just cleaning site cookies worked here.
In my case i had to switch off "Adblock extension" from chrome.

How to prevent app from crashing on uncaughtErrorEvent

Is there a way to prevent the app from crashing when JS uncaught errors occur?
Already tried to wrap app.start(...) inside try/catch, but it sure doesn't work:)
There is indeed, you can register an uncaughtErrorEvent listener.
Refer to the official documentation - https://docs.nativescript.org/core-concepts/application-lifecycle#use-application-events
You can drop the following in your app.js before bootstrapping the application
var application = require("application");
application.on(application.uncaughtErrorEvent, function (args) {
if (args.android) {
// For Android applications, args.android is an NativeScriptError.
console.log("NativeScriptError: " + args.android);
} else if (args.ios) {
// For iOS applications, args.ios is NativeScriptError.
console.log("NativeScriptError: " + args.ios);
}
});
There's no way to prevent the app from crashing. You can catch the error in the uncaughtError application event but the app will crash afterwards regardless.
Attempting to navigate to an error page won't work.
According to the comments on this GitHub issue:
Ability to specify custom error pages on uncaughtErrors · Issue #1718 · NativeScript/NativeScript
there is a way to customize the error page shown, but only on Android. Apparently there isn't anything similar available for iOS.
This is an older question but there is a documented way to prevent this using Nativescript older than 4.2 (you should be on 6+ now)
Disable rethrowing of uncaught js exceptions to native
Basically, catch the JS errors but do not crash the native app.
Note the disclaimer there as well. The script will be unstable at this point. Yes, it did not crash, but wherever it dies did not continue, so you might be worse off for stability. Putting the app in a bad state or just quitting/recrashing might be safer.

Content Security Policy: Couldn't parse invalid source chrome-extension

I'm getting a new error in my JS console on Firefox and I haven't changed the code.
I don't get this error in other browsers and doesn't seem to affect the functionality of my code.
It's obviously in some way related to Firefox, but it seems to be pointing the error out to my async loaded facebook JS SDK.
Anybody else using that SDK seeing this in Firefox now? Any help or insight?
This is the full message:
Content Security Policy: Couldn't parse invalid source chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl
and this is the line in the fb JS SDK:
*/__d("JSON3",[],function(a,b,c,d,e,f){(function(){var g={}.toString,h,i,j,k=e.exports={},l='{"A":[1,true,false,null,"\\u0000\\b\\n\\f\\r\\t"]}',m,n,o,p,q,r,s,t,u,v,w,x,y,z,aa,ba=new Date(-3509827334573292),ca,da,ea;try{ba=ba.getUTCFullYear()==-109252&&ba.getUTCMonth()===0&&ba.getUTCDate()==1&&ba.getUTCHours()==10&&ba.getUTCMinutes()==37&&ba.getUTCSeconds()==6&&ba.getUTCMilliseconds()==708;}catch(fa){}if(!ba){ca=Math.floor;da=[0,31,59,90,120,151,181,212,243,273,304,334];ea=function(ga,ha){return da[ha]+365*(ga-1970)+ca((ga-1969+(ha=+(ha>1)))/4)-ca((ga-1901+ha)/100)+ca((ga-1601+ha)/400);};}if(typeof JSON=="object"&&JSON){k.stringify=JSON.stringify;k.parse=JSON.parse;}if((m=typeof k.stringify=="function"&&!ea)){(ba=function(){return 1;}).toJSON=ba;try{m=k.stringify(0)==="0"&&k.stringify(new Number())==="0"&&k.stringify(new String())=='""'&&k.stringify(g)===j&&k.stringify(j)===j&&k.stringify()===j&&k.stringify(ba)==="1"&&k.stringify([ba])=="[1]"&&k.stringify([j])=="[null]"&&k.stringify(null)=="null"&&k.stringify([j,g,null])=="[null,null,null]"&&k.stringify({result:[ba,true,false,null,"\0\b\n\f\r\t"]})==l&&k.stringify(null,ba)==="1"&&k.stringify([1,2],null,1)=="[\n 1,\n 2\n]"&&k.stringify(new Date(-8.64e+15))=='"-271821-04-20T00:00:00.000Z"'&&k.stringify(new Date(8.64e+15))=='"+275760-09-13T00:00:00.000Z"'&&k.stringify(new Date(-62198755200000))=='"-000001-01-01T00:00:00.000Z"'&&k.stringify(new Date(-1))=='"1969-12-31T23:59:59.999Z"';}catch(fa){m=false;}}if(typeof k.parse=="function")try{if(k.parse("0")===0&&!k.parse(false)){ba=k.parse(l);if((r=ba.A.length==5&&ba.A[0]==1)){try{r=!k.parse('"\t"');}catch(fa){}if(r)try{r=k.parse("01")!=1;}catch(fa){}}}}catch(fa){r=false;}ba=l=null;if(!m||!r){if(!(h={}.hasOwnProperty))h=function(ga){var ha={},ia;if((ha.__proto__=null,ha.__proto__={toString:1},ha).toString!=g){h=function(ja){var ka=this.__proto__,la=ja in (this.__proto__=null,this);this.__proto__=ka;return la;};}else{ia=ha.constructor;h=function(ja){var ka=(this.constructor||ia).prototype;return ja in this&&!(ja in ka&&this[ja]===ka[ja]);};}ha=null;return h.call(this,ga);};i=function(ga,ha){var ia=0,ja,ka,la,ma;(ja=function(){this.valueOf=0;}).prototype.valueOf=0;ka=new ja();for(la in ka)if(h.call(ka,la))ia++;ja=ka=null;if(!ia){ka=["valueOf","toString","toLocaleString","propertyIsEnumerable","isPrototypeOf","hasOwnProperty","constructor"];ma=function(na,oa){var pa=g.call(na)=="[object Function]",qa,ra;for(qa in na)if(!(pa&&qa=="prototype")&&h.call(na,qa))oa(qa);for(ra=ka.length;qa=ka[--ra];h.call(na,qa)&&oa(qa));};}else if(ia==2){ma=function(na,oa){var pa={},qa=g.call(na)=="[object Function]",ra;for(ra in na)if(!(qa&&ra=="prototype")&&!h.call(pa,ra)&&(pa[ra]=1)&&h.call(na,ra))oa(ra);};}else ma=function(na,oa){var pa=g.call(na)=="[object Function]",qa,ra;for(qa in na)if(!(pa&&qa=="prototype")&&h.call(na,qa)&&!(ra=qa==="constructor"))oa(qa);if(ra||h.call(na,(qa="constructor")))oa(qa);};return ma(ga,ha);};if(!m){n={"\\":"\\\\",'"':'\\"',"\b":"\\b","\f":"\\f","\n":"\\n","\r":"\\r","\t":"\\t"};o=function(ga,ha){return ("000000"+(ha||0)).slice(-ga);};p=function(ga){var ha='"',ia=0,ja;for(;ja=ga.charAt(ia);ia++)ha+='\\"\b\f\n\r\t'.indexOf(ja)>-1?n[ja]:ja<" "?"\\u00"+o(2,ja.charCodeAt(0).toString(16)):ja;return ha+'"';};q=function(ga,ha,ia,ja,ka,la,ma){var na=ha[ga],oa,pa,qa,ra,sa,ta,ua,va,wa,xa,ya,za,ab,bb,cb;if(typeof na=="object"&&na){oa=g.call(na);if(oa=="[object Date]"&&!h.call(na,"toJSON")){if(na>-1/0&&na<1/0){if(ea){ra=ca(na/86400000);for(pa=ca(ra/365.2425)+1970-1;ea(pa+1,0)<=ra;pa++);for(qa=ca((ra-ea(pa,0))/30.42);ea(pa,qa+1)<=ra;qa++);ra=1+ra-ea(pa,qa);sa=(na%86400000+86400000)%86400000;ta=ca(sa/3600000)%24;ua=ca(sa/60000)%60;va=ca(sa/1000)%60;wa=sa%1000;}else{pa=na.getUTCFullYear();qa=na.getUTCMonth();ra=na.getUTCDate();ta=na.getUTCHours();ua=na.getUTCMinutes();va=na.getUTCSeconds();wa=na.getUTCMilliseconds();}na=(pa<=0||pa>=10000?(pa<0?"-":"+")+o(6,pa<0?-pa:pa):o(4,pa))+"-"+o(2,qa+1)+"-"+o(2,ra)+"T"+o(2,ta)+":"+o(2,ua)+":"+o(2,va)+"."+o(3,wa)+"Z";}else na=null;}else if(typeof na.toJSON=="function"&&((oa!="[object Number]"&&oa!="[object String]"&&oa!="[object Array]")||h.call(na,"toJSON")))na=na.toJSON(ga);}if(ia)na=ia.call(ha,ga,na);if(na===null)return "null";oa=g.call(na);if(oa=="[object Boolean]"){return ""+na;}else if(oa=="[object Number]"){return na>-1/0&&na<1/0?""+na:"null";}else if(oa=="[object String]")return p(na);if(typeof na=="object"){for(ab=ma.length;ab--;)if(ma[ab]===na)throw TypeError();ma.push(na);xa=[];bb=la;la+=ka;if(oa=="[object Array]"){for(za=0,ab=na.length;za<ab;cb||(cb=true),za++){ya=q(za,na,ia,ja,ka,la,ma);xa.push(ya===j?"null":ya);}return cb?(ka?"[\n"+la+xa.join(",\n"+la)+"\n"+bb+"]":("["+xa.join(",")+"]")):"[]";}else{i(ja||na,function(db){var eb=q(db,na,ia,ja,ka,la,ma);if(eb!==j)xa.push(p(db)+":"+(ka?" ":"")+eb);cb||(cb=true);});return cb?(ka?"{\n"+la+xa.join(",\n"+la)+"\n"+bb+"}":("{"+xa.join(",")+"}")):"{}";}ma.pop();}};k.stringify=function(ga,ha,ia){var ja,ka,la,ma,na,oa;if(typeof ha=="function"||typeof ha=="object"&&ha)if(g.call(ha)=="[object Function]"){ka=ha;}else if(g.call(ha)=="[object Array]"){la={};for(ma=0,na=ha.length;ma<na;oa=ha[ma++],((g.call(oa)=="[object String]"||g.call(oa)=="[object Number]")&&(la[oa]=1)));}if(ia)if(g.call(ia)=="[object Number]"){if((ia-=ia%1)>0)for(ja="",ia>10&&(ia=10);ja.length<ia;ja+=" ");}else if(g.call(ia)=="[object String]")ja=ia.length<=10?ia:ia.slice(0,10);return q("",(oa={},oa[""]=ga,oa),ka,la,ja,"",[]);};}if(!r){s=String.fromCharCode;t={"\\":"\\",'"':'"',"/":"/",b:"\b",t:"\t",n:"\n",f:"\f",r:"\r"};u=function(){z=aa=null;throw SyntaxError();};v=function(){var ga=aa,ha=ga.length,ia,ja,ka,la,ma;while(z<ha){ia=ga.charAt(z);if("\t\r\n ".indexOf(ia)>-1){z++;}else if("{}[]:,".indexOf(ia)>-1){z++;return ia;}else if(ia=='"'){for(ja="#",z++;z<ha;){ia=ga.charAt(z);if(ia<" "){u();}else if(ia=="\\"){ia=ga.charAt(++z);if('\\"/btnfr'.indexOf(ia)>-1){ja+=t[ia];z++;}else if(ia=="u"){ka=++z;for(la=z+4;z<la;z++){ia=ga.charAt(z);if(!(ia>="0"&&ia<="9"||ia>="a"&&ia<="f"||ia>="A"&&ia<="F"))u();}ja+=s("0x"+ga.slice(ka,z));}else u();}else{if(ia=='"')break;ja+=ia;z++;}}if(ga.charAt(z)=='"'){z++;return ja;}u();}else{ka=z;if(ia=="-"){ma=true;ia=ga.charAt(++z);}if(ia>="0"&&ia<="9"){if(ia=="0"&&(ia=ga.charAt(z+1),ia>="0"&&ia<="9"))u();ma=false;for(;z<ha&&(ia=ga.charAt(z),ia>="0"&&ia<="9");z++);if(ga.charAt(z)=="."){la=++z;for(;la<ha&&(ia=ga.charAt(la),ia>="0"&&ia<="9");la++);if(la==z)u();z=la;}ia=ga.charAt(z);if(ia=="e"||ia=="E"){ia=ga.charAt(++z);if(ia=="+"||ia=="-")z++;for(la=z;la<ha&&(ia=ga.charAt(la),ia>="0"&&ia<="9");la++);if(la==z)u();z=la;}return +ga.slice(ka,z);}if(ma)u();if(ga.slice(z,z+4)=="true"){z+=4;return true;}else if(ga.slice(z,z+5)=="false"){z+=5;return false;}else if(ga.slice(z,z+4)=="null"){z+=4;return null;}u();}}return "$";};w=function(ga){var ha,ia,ja;if(ga=="$")u();if(typeof ga=="string"){if(ga.charAt(0)=="#")return ga.slice(1);if(ga=="["){ha=[];for(;;ia||(ia=true)){ga=v();if(ga=="]")break;if(ia)if(ga==","){ga=v();if(ga=="]")u();}else u();if(ga==",")u();ha.push(w(ga));}return ha;}else if(ga=="{"){ha={};for(;;ia||(ia=true)){ga=v();if(ga=="}")break;if(ia)if(ga==","){ga=v();if(ga=="}")u();}else u();if(ga==","||typeof ga!="string"||ga.charAt(0)!="#"||v()!=":")u();ha[ga.slice(1)]=w(v());}return ha;}u();}return ga;};y=function(ga,ha,ia){var ja=x(ga,ha,ia);if(ja===j){delete ga[ha];}else ga[ha]=ja;};x=function(ga,ha,ia){var ja=ga[ha],ka;if(typeof ja=="object"&&ja)if(g.call(ja)=="[object Array]"){for(ka=ja.length;ka--;)y(ja,ka,ia);}else i(ja,function(la){y(ja,la,ia);});return ia.call(ga,ha,ja);};k.parse=function(ga,ha){z=0;aa=ga;var ia=w(v());if(v()!="$")u();z=aa=null;return ha&&g.call(ha)=="[object Function]"?x((ba={},ba[""]=ia,ba),"",ha):ia;};}}}).call(this);});
I solved this same problem for myself after recently posting it as a Facebook bug on https://developers.facebook.com/x/bugs/729597157070762/ With FB's help I noticed the following unwanted browser extensions in Firefox: Searchme, Slick Savings, Amazon Shopping Assistant, and Ebay Shopping Assistant. Turns out these are essentially malware that effected Firefox, Safari, and Chrome on my Mac. They're made by a company called Spigot, Inc.
While searching for an effective means of virus removal I found this link http://www.thesafemac.com/arg-spigot/ which gives detailed instructions how to do so.
I hope this helps you kevin!
Unfortunately a month or so after my original answer (above) the same error and warnings came back for me but just as of yesterday, 4/22/2014 they changed to these 5 warnings, instead:
Content Security Policy: allow directive is deprecated, use the equivalent
default-src directive instead
...conds();wa=na.getUTCMilliseconds();}na=(pa<=0||pa>=10000?(pa<0?"-":"+")+o(6,pa<0...
all.js (line 27)
The X-Content-Security-Policy and X-Content-Security-Report-Only headers will be deprecated in the future. Please use the Content-Security-Policy and Content-Security-Report-Only headers with CSP spec compliant syntax instead.
"Content Security Policy: allow directive is deprecated, use the equivalent default-src directive instead"
"The X-Content-Security-Policy and X-Content-Security-Report-Only headers will be deprecated in the future. Please use the Content-Security-Policy and Content-Security-Report-Only headers with CSP spec compliant syntax instead."
Use of getPreventDefault() is deprecated. Use defaultPrevented instead.
{href:function(a){return a.getAttribute("href")},type:function(a){return a.getAt
jquery.min.js (line 3)
My guess is that the errors/warnings are due to the way the Facebook like button is engineered and how it interacts with Firefox and other browsers. The change in warnings and errors to these new warnings seems to indicate that Facebook and or Mozilla are working on this issue and will hopefully fix it...???
yesterday, 4/29/2014 This was officially classified as a Facebook known bug issue I created and is currently being addressed. Below is text from the FB email to me:
The bug you are subscribed to "like button works but errors show onload in firebug "Content Security Policy: Failed to parse unrecognized source chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl"" has been updated:
Status has changed: Closed → Assigned
Hi All, We have managed to reproduce this issue and it appears to be a valid bug. We are assigning this to the appropriate team. This might take some time to fix but we will do our best to keep you updated on the progress of this bug as soon as we can. Thanks
today, 5/07/2014 I just received an email from Facebook stating,
"Status has changed: Assigned → Fixed
This should now be resolved. Thanks for your patience."
Looks good on my end, no longer an issue.
I deleted all FF extensions, and started from clean FF 28 installation.
Installed firebug and user agent overrider add-ons and did not get this error.
Then, I changed user agent and an error shows up on some agents and does not on some.
Error shows up on following agents:
Mac / chrome 32
linux / chrome 32
windows / chrome 32
Android / chrome 32
FYI,
I recently encountered this issue while adding the Facebook javascript login while working in Firefox (28) Private browsing.
I noticed that my Firebug console would consistenly display
"Couldn't parse invalid source chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl" etc...
It wasn't until I closed my browser completely that this message went away.
This meant that while I was testing my app I would need to completely close out of my browser to refresh the application, not just my private windows but all windows and console log windows as well.
I did not test this in other browsers just Firefox 28.

What causes FF to produce SSL_ERROR_BAD_MAC_READ?

We have a web application where sometimes the request are broken on irregular basis and only using the Firefox browser the error that comes up is :
SSL_ERROR_BAD_MAC_READ
-12273
"SSL received a record with an incorrect Message Authentication Code."
One customer claimes that they have this error about every 3 minutes but the others doesn't have this problem, but the other customers have this problem only a few times.
Any idea how find out the source of that problem?
I browsed a little through the Firefox code and found that
if (NSS_SecureMemcmp(mac, pBuf, macLen) != 0) {
/* MAC's didn't match... */
SSL_DBG(("%d: SSL[%d]: mac check failed, seq=%d",
SSL_GETPID(), ss->fd, ss->sec.rcvSequence));
PRINT_BUF(1, (ss, "computed mac:", mac, macLen));
PRINT_BUF(1, (ss, "received mac:", pBuf, macLen));
PORT_SetError(SSL_ERROR_BAD_MAC_READ);
rv = SECFailure;
goto cleanup;
}
Obviously it is possible to see what was the received mac and what was the computed mac...anyone know where those logs are in FF or maybe I should enable some logging in FF?
Where can I find the logs for this in Firefox?
We upgraded openSSL to the latest version available for our platform, and it worked. The problem is gone, so it was probably a bug in the openSSL implementation.
This could be an issue with SSL implementation you are using. MAC is like hash of the ssl packet transferred. If the ssl packet is not flushed properly by the implementation (eating some byes or not flushing completely) you will see these kind of issues.
I opened the cmd window and used the ipconfig /flushdns command while FF was closed. I reopened it and I was able to access the URL successfully.

Resources