{"id":5536,"date":"2019-05-01T22:23:34","date_gmt":"2019-05-01T20:23:34","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=5536"},"modified":"2019-05-01T22:23:34","modified_gmt":"2019-05-01T20:23:34","slug":"inspecting-one-of-the-most-famous-javascript-bugs-of-all-time","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2019\/05\/01\/inspecting-one-of-the-most-famous-javascript-bugs-of-all-time\/","title":{"rendered":"Inspecting one of the most famous JavaScript bugs of all time"},"content":{"rendered":"

One fine day evening, after writing a handful of beautiful JavaScript code, sipping your coffee, you smile\u200a\u2014\u200athe code looks especially\u2026<\/p><\/blockquote>\n

After reading Inspecting one of the most famous JavaScript bugs of all time<\/a> one may wonder how such flaws does not “explode” in the face of every developer, subtle as it is<\/em><\/p>\n

<\/p>\n

\n

Inspecting one of the most famous JavaScript bugs of all\u00a0time.<\/h1>\n
\n
\"Go<\/a><\/div>\n
\n
aiswarya krishna<\/a><\/div>\n<\/div>\n<\/div>\n
\n
<\/div>\n
<\/div>\n<\/div>\n
\n
\n
<\/div>\n<\/div>\n<\/figure>\n

One fine day evening, after writing a handful of beautiful JavaScript code, sipping your coffee, you smile\u200a\u2014\u200athe code looks especially beautiful today, and you feel a sense or serenity filling your head.<\/p>\n

Then you decide to fire up your debug console and take a look at the memory consumption, and the performance.<\/p>\n

You take one peek at the console inspector and the sense of serenity is long gone, and something sends chills down your spine.<\/p>\n

The trace shows a mounting slope that resembles the temperature graph of planet Earth. It\u2019s bad. Quite bad.<\/p>\n

You are leaking memory. And even forcing the GC to do a force sweep doesn\u2019t do you any favors. Your once-so-beautiful code is now a tangled mess of leaky logic.<\/p>\n

As developers, we all have gone through this scenario before. We have coded, inspected and spent days racking our brains over leaky code.<\/p>\n

But the below sets a new standard for leaky code. And it required a new diagnosis to isolate and fix it.<\/p>\n

Here, I am dissecting one of the most famous JavaScript bugs of all time, and yes, it was caused by a faulty implementation of closure.<\/p>\n

Let\u2019s jump right in.<\/p>\n

Imagine the following code:<\/p>\n

var theThing = null;<\/pre>\n
var replaceThing = function ()<\/pre>\n
        {<\/pre>\n
var originalThing = theThing;<\/pre>\n
 theThing = {\n            longStr: new Array(1000000).join(\u2018*\u2019)\n            };<\/pre>\n
        };<\/pre>\n
setInterval(replaceThing, 1000);<\/pre>\n
Every second, the replaceThing function will be executed. theThing variable will be replaced with a new object containing a gigantic string. Before that, the original value of theThing is saved in a local variable originalThing. After the function is returned, the old value of theThing can be garbage collected, which also happens to collect the long string inside it, because nothing refers to it anymore.<\/p>\n
So the memory allocation is pretty straightforward: it allocates a big string at every iteration of the function, and at the same time, it deletes the previous big string. So there are no further references to originalThing and theThing, which leads to their collection.<\/p>\n
Not a big deal huh?<\/p>\n
But what if we had a certain specific set of needs that required us to create a closure inside replaceThing, thereby outlasting replaceThing?<\/p>\n
Like in the following code:<\/p>\n
var theThing = null;<\/pre>\n
var replaceThing = function ()<\/pre>\n
{<\/pre>\n
var originalThing = theThing;<\/pre>\n
theThing = {<\/pre>\n
            longStr: new Array(1000000).join(\u2018*\u2019),<\/pre>\n
            someMethod: function () {<\/pre>\n
                        console.log(someMessage);<\/pre>\n
                                    }<\/pre>\n
           };<\/pre>\n
};<\/pre>\n
setInterval(replaceThing, 1000);<\/pre>\n
Now there is a new function \u201csomeMethod\u201d inside theThing object. This sets up a closure scope. This is another way of saying that someMethod needs access to originalThing and theThing even after the function replaceThing has exited. I mean, that\u2019s the entire point of closures right? So this can lead to boundless memory growth, since each iteration of the replaceThing function, creates its own version of theThing and that version would point to the previous version through originalThing.<\/p>\n
Fortunately, most JavaScript runtimes (that run behind Chrome, Node and React) are smart enough to understand that originalThing is not actually used in the closure \u201csomeMethod\u201d. So it is not put into someMethod\u2019s closure scope, and is eventually GC\u2019d when the function replaceThing exits.<\/p>\n
Lucky for us, there is no reference ever anywhere to originalThing.<\/p>\n
Wow. So far so good.<\/p>\n
So next level down, we bring in the big guns.<\/strong><\/p>\n
What if we had a reference somewhere to originalThing, that requires the closure to hold onto originalThing?<\/p>\n
That would make things ugly.<\/p>\n
var theThing = null;<\/pre>\n
var replaceThing = function () {\nvar originalThing = theThing;<\/pre>\n
var unused =  function () {<\/pre>\n
 if (originalThing)\n     console.log(\u201chi\u201d);<\/pre>\n
             };<\/pre>\n
     theThing = {\n                 longStr: new Array(1000000).join(\u2018*\u2019),\n                 someMethod: function () {\n                             console.log(someMessage);<\/pre>\n
                 }<\/pre>\n
                };<\/pre>\n
setInterval(replaceThing, 1000);<\/pre>\n
Fire up your console and take a look.<\/p>\n
We\u2019re using an extra megabyte every second! So it looks like we are leaking longStr.<\/p>\n
But nothing seems to have changed. OriginalThing is referenced in only two places. One is in the main body of the function replaceThing, and the other is inside the function unused. Both of these get cleaned up once replaceThing ends. We don\u2019t even run the function \u201cunused\u201d\u00a0. The only stuff that escapes the destruction of replaceThing is the closure created around \u201csomeMethod\u201d. Surprisingly, someMethod doesn\u2019t event refer to originalString!<\/p>\n
This behaviour has a lot to do with the way closures are implemented in JavaScript.<\/p>\n
In JavaScript, as we already know, every function is an object. This object has access to another object that represents its scope. So, if a function has access to three variables a, b and c, the function will have access to dictionary style object with its own scope\u200a\u2014\u200acontaining a, b and c.<\/p>\n
This dictionary styled object is the function\u2019s lexical environment.<\/strong><\/p>\n
So in our case, both the functions \u201cunused\u201d and \u201csomeMethod\u201d has access to the same lexical environment (or scope). This environment is their closure scope. It is imperative that this scope is shared between all the functions that has access to it.<\/p>\n
That means if we have three functions, sample1, sample2 and sample3, all of them are inside a main function named \u201cmainFun\u201d. Imagine that there is a variable a, in the main body of mainFun.<\/p>\n
function mainFun()   {<\/pre>\n
var a = 10;\nvar sample1 = function () {\n              console.log(a);\n              };<\/pre>\n
var sample2 = function () {\n              console.log(a);\n               };<\/pre>\n
var sample3 = function () {\n               console.log(a);\n               };<\/pre>\n
                      }<\/pre>\n
The runtime needs to make sure that the three functions sample1, sample2 and sample3 need to have access to the same \u201ca\u201d.<\/p>\n
This is the same thing that happens in our case with \u201cunused\u201d and \u201csomeMethod\u201d. Both of them share the same lexical scope. Both of them have access to the same \u201coriginalThing\u201d. But as we have already discussed, V8 is smart enough to keep originalThing out of lexical scope (to make them available for GC) if they are not referenced by any functions. This is why the first example doesn\u2019t leak.<\/p>\n
But as soon as the function \u201cunused\u201d references it, originalThing ends up in the lexical scope, which is not GC\u2019d. This leads to boundless memory leak.<\/p>\n
This bug was discovered in the Meteor framework.<\/p>\n
How to solve this bug?<\/p>\n
Simple!<\/p>\n
Just add one single line:<\/p>\n
originalThing = null<\/pre>\n
to the end of replaceThing. This way, after each function iteration, the name originalThing will exist in the lexical scope of someMethod, but there will not be a link to the long string.<\/p>\n
var theThing = null;<\/pre>\n
var replaceThing = function () {\nvar originalThing = theThing;<\/pre>\n
var unused = function () {<\/pre>\n
   if (originalThing)\n       console.log(\u201chi\u201d);<\/pre>\n
     };<\/pre>\n
theThing = {\n            longStr: new Array(1000000).join(\u2018*\u2019),\n            someMethod: function () {}<\/pre>\n
           };<\/pre>\n
originalThing = null;<\/pre>\n
};<\/pre>\n
setInterval(replaceThing, 1000);<\/pre>\n
There you go! So have a nice time until we meet again.<\/p>\n
This is my learning blog. I write as I learn new things. This blog and codes are inspired from an Original bug discovered in the Meteor\u2019s live HTML template rendering system. The Original blog post is here<\/a>.<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
One fine day evening, after writing a handful of beautiful JavaScript code, sipping your coffee, you smile\u200a\u2014\u200athe code looks especially\u2026 After reading Inspecting one of the most famous JavaScript bugs of all time one may wonder how such flaws does not “explode” in the face of every developer, subtle as it is<\/p>\n
Read more →<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"link","meta":{"inline_featured_image":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[50],"tags":[],"class_list":["post-5536","post","type-post","status-publish","format-link","hentry","category-javascript","post_format-post-format-link"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6daft-1ri","jetpack-related-posts":[{"id":8197,"url":"https:\/\/monodes.com\/predaelli\/2021\/02\/25\/a-post-mortem-in-5-acts-of-how-microsoft-privatized-open-source-killing-javascript-in-the-process\/","url_meta":{"origin":5536,"position":0},"title":"A Post-Mortem in 5 Acts, of How Microsoft Privatized Open Source, killing JavaScript in the Process","author":"Paolo Redaelli","date":"2021-02-25","format":"link","excerpt":"A Post-Mortem in 5 Acts, of How Microsoft Privatized Open Source, killing JavaScript in the Process After Microsoft\u2019s blitzkrieg take-over, the Open Source JavaScript community, as we know it, is coming to an end. Alex KleydintsFeb 6\u00b79 min read All things said and done, you must stand in awe, at\u2026","rel":"","context":"In "Ethics"","block_context":{"text":"Ethics","link":"https:\/\/monodes.com\/predaelli\/category\/ethics\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4792,"url":"https:\/\/monodes.com\/predaelli\/2018\/10\/28\/telosys-code-generator-for-java-javascript-python-nodejs-php-c-etc\/","url_meta":{"origin":5536,"position":1},"title":"Telosys code generator for Java, JavaScript, Python, NodeJS, PHP, C#, etc","author":"Paolo Redaelli","date":"2018-10-28","format":false,"excerpt":"Telosys is a free code generator usable with different languages or frameworks : Java, JavaScript, Python, NodeJS, PHP, GoLang, C#, Angular, VueJS, etc Sorgente: Telosys code generator for Java, JavaScript, Python, NodeJS, PHP, C#, etc","rel":"","context":"In "Senza categoria"","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":5254,"url":"https:\/\/monodes.com\/predaelli\/2019\/02\/17\/learn-pure-functions-with-javascript-cristi-salcescu-medium\/","url_meta":{"origin":5536,"position":2},"title":"Learn pure functions with JavaScript \u2013 Cristi Salcescu \u2013 Medium","author":"Paolo Redaelli","date":"2019-02-17","format":"link","excerpt":"Pure functions are easier to read, understand, test, debug and munch more. Source: Learn pure functions with JavaScript \u2013 Cristi Salcescu \u2013 Medium Learn pure functions with JavaScript Cristi Salcescu Feb 10 Photo by Ren\u00e9 Reichelt on\u00a0Unsplash Pure functions are easier to read, understand, test, debug and munch more. You\u2026","rel":"","context":"In "Documentations"","block_context":{"text":"Documentations","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4677,"url":"https:\/\/monodes.com\/predaelli\/2018\/10\/22\/conditional-javascript-for-experts-hacker-noon\/","url_meta":{"origin":5536,"position":3},"title":"Conditional JavaScript for Experts \u2013 Hacker Noon","author":"Paolo Redaelli","date":"2018-10-22","format":false,"excerpt":"Mastery of conditional expressions for cleaner codes They say in Conditional JavaScript for Experts \u2013 Hacker Noon. What they are suggesting is to use side-effects of\u00a0 \"expression\", as Javascript does not separate commands and queries. Call me dogmatic but this behavior to look like a fundamental ingredient for disaster. In\u2026","rel":"","context":"In "Eiffel"","block_context":{"text":"Eiffel","link":"https:\/\/monodes.com\/predaelli\/category\/eiffel\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":297,"url":"https:\/\/monodes.com\/predaelli\/2015\/06\/12\/javascript-other-languages\/","url_meta":{"origin":5536,"position":4},"title":"JavaScript + Other Languages","author":"Paolo Redaelli","date":"2015-06-12","format":"link","excerpt":"JavaScript+OtherLanguages Those slides JavaScript + Other Languages are really useful to implement an eventual Eiffel to JavaScript compiler. Well, actually it should be called transcompiler.... We could just feed the C files made by current Liberty compiler but it seems to me that passing throught C which is a procedural\u2026","rel":"","context":"In "Eiffel"","block_context":{"text":"Eiffel","link":"https:\/\/monodes.com\/predaelli\/category\/eiffel\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":5130,"url":"https:\/\/monodes.com\/predaelli\/2019\/01\/15\/intuitive-asynchronous-javascript-edwin-yung-medium\/","url_meta":{"origin":5536,"position":5},"title":"Intuitive Asynchronous Javascript \u2013 Edwin Yung \u2013 Medium","author":"Paolo Redaelli","date":"2019-01-15","format":false,"excerpt":"Escape callback hell! Source: Intuitive Asynchronous Javascript \u2013 Edwin Yung \u2013 Medium \u00a0 Asynchronous Javascript Explained Simply and Intuitively Edwin Yung Dec 29, 2017 Escape callback hell with this\u00a0article! Asynchronous Javascript is difficult to wrangle. The following is my quick attempt to elucidate their inner workings. Before we get started,\u2026","rel":"","context":"In "Documentations"","block_context":{"text":"Documentations","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/5536","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/comments?post=5536"}],"version-history":[{"count":0,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/5536\/revisions"}],"wp:attachment":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/media?parent=5536"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/categories?post=5536"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/tags?post=5536"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}