Summary of reasons why websites cause browsers to crash (various browsers) Recommended_javascript skills

When interviewing with a certain company, the interviewer asked, what are the causes of browser crashes? I am a fool and I only answered the question of memory leak. In fact, during the loading process of web pages, the browser's response often becomes very slow due to various reasons, or the browser loses response, or even causes the machine to be unable to perform other operations.

For visitors, if they log in to your website, the browser will crash immediately. I think this is intolerable to everyone. Here is a summary of the reasons why the website causes the browser to crash:

1. Memory leak

Let’s talk about memory leaks first. There are two situations when a website crashes due to a memory leak, the server crashes and the browser crashes. The problem caused by a memory leak is obvious, it causes the reference to the allocated memory to be lost, and the process will continue to use the memory as long as the system is still running. The result of this is that programs that once occupied more memory will reduce system performance until the machine stops working completely and the memory will be completely cleared.

Apache’s web server is written in C/C. Needless to say, there is a memory leak problem in C/C. There is unrecoverable memory in the system, which sometimes causes insufficient memory or system crash. In Java, a memory leak means that there are some allocated reachable but useless objects. These objects will not be recycled by GC, but they occupy memory.

On the client side, memory leaks caused by JavaScript may also cause the browser to crash. The more authoritative articles about memory leaks in JavaScript include "Memory leak patterns in JavaScript" and "Understanding and Solving Internet Explorer Leak Patterns》.

JavaScript is a garbage collector (GC) language, which means that memory is allocated to an object based on its creation and will be reclaimed by the browser when there are no references to the object. According to the article "Fabulous Adventures In Coding": "JScript uses a nongenerational mark-and-sweep garbage collector.", "nongenerational mark-and-sweep" can be used Understood in this way, the browser does not use pure garbage collection to process JavaScript, but also uses reference counting to handle memory for Native objects (such as Dom, ActiveX Object).

In a reference counting system, each referenced object keeps a count to know how many objects are referencing it. If the count reaches zero, the object is destroyed and the memory it occupied is returned to the heap. When objects refer to each other, a circular reference is formed. Browsers (IE6, Firefox2.0) can correctly handle circular references between pure JavaScript objects, but due to the reference counting system, mutual references Objects cannot be destroyed because the reference count can never be zero, so the browser cannot handle circular references between JavaScript and Native objects (such as Dom, ActiveX Object). Therefore, when we have a circular reference between Native objects and JavaScript objects, memory leaks will occur.

Simply put, the browser uses reference counting to handle memory for Native objects, and reference counted objects cannot be destroyed. Circular references involving Native objects will cause memory leaks. Using the following example and understanding this sentence, you can basically understand the memory leak caused by JavaScript.

Copy code The code is as follows:

var obj;
window.onload = function( ){
// The reference of the JavaScript object obj to the DOM object is obtained according to the id
obj=document.getElementById("DivElement");
　 // The DOM object has a reference to this JavaScript object, which is obtained by expandoProperty implementation
　document.getElementById("DivElement").expandoProperty=obj;
};

It can be seen that a circular reference is generated between the JavaScript object and the DOM object. Since DOM objects are managed via reference counting, neither object will be destroyed.

Another situation is in closures. When we encounter closures and bind event response codes to Native objects, it is easy to create Closure Memory Leak. The key reason is the same as the former, which is also a circular reference across JavaScript objects and Native objects. It's just that the code is more hidden.

Copy code The code is as follows:

window.onload = function AttachEvents(element){
//element has a reference to the function ClickEventHandler()
　element.attachEvent( " onclick " , ClickEventHandler);
function ClickEventHandler( ){
//This function has a reference pointing to AttachEvents(element) to call Scope,
　 //That is, the parameter element is executed.
　}
}

Here is a simple understanding of the reasons why JavaScript causes memory leaks. Memory leaks increase the burden on the browser and are likely to cause the browser to crash. All we have to do is Try to avoid this situation. You can refer to the above mentioned "Memory leak patterns in JavaScript" and "Understanding and Solving Internet Explorer Leak Patterns 》Two articles to understand. The ultimate goal of dealing with JavaScript memory leaks is to break the circular reference between JavaScript objects and Native objects or to clear the reference count and release the object.

Some memory leaks, such as closure memory leaks, may be difficult for us to detect. To detect memory leaks, we may refer to "Javascript Memory Leak Tool Use".

2. Complex web page code and browser bug

The emergence of a large number of personal websites and low-quality website codes has resulted in a general lack of support for browsing standards. If you happen to encounter some bugs in the browser, the browser rendering engine will make errors when processing these web page codes, such as crashing. Loop or direct crash, etc.

HTML code causes website to crash

This is an HTML structure error that causes IE6 to crash. Adding any characters before or after

will cause IE6 to crash.

Copy code The code is as follows:

BR>"http://www.w3.org/TR/html4/loose.dtd">

head>

This code comes from a Korean website, no matter what version of XHTML or HTML is used, as long as the DOCTYPE declaration is included, IE6 will crash immediately. When there is no DOCTYPE declaration, there will be no error. The reason may be related to the document type declaration.

CSS code that crashes IE6

　The code is referenced from the website Cats who Code. The bug was discovered in 2007 and is said to have been discovered by a Japanese:

Copy code The code is as follows:

The reason is that it is placed directly in the table Content, in IE6, it will cause the mshtml.dll module to be damaged and close the browser. If it is not IE6, it will be safe.

In addition, the bug that exists in IE6 also has the following situation. This problem will also be encountered when the pseudo class is a:active:

Copy code The code is as follows:

Crash IE6, crash ie6

Solution : Add zoom:1; to to trigger haslayout.

Copy code The code is as follows:

CSS code that crashes IE7

This bug comes from Stealing Rice. It only exists in IE7. It is estimated that it causes IE7 to crash when processing omitted words.

Copy code The code is as follows:

Solution: Add zoom:1; to

to trigger haslayout

JavaScript code that crashes IE6

　From Internet Explorer Sucks, this website uses some code. When you visit it using IE6, the browser will crash immediately. The code is as follows:

Copy code The code is as follows:

<script>for (x in document .write) { document.write(x);}</script>

The specific cause cannot be analyzed for the time being, but in terms of compatibility and execution efficiency, this method of writing is generally not adopted.

3. Too much data on the webpage

Web pages contain a large amount of data that needs to be processed, causing the system to be busy, such as multi-image pages, very long pages, etc., or various controls embedded in the web page will cause the browser to process a large amount of data, causing the system to be busy. Such as Flash games, ActiveX controls, etc. When a browser accesses a website, if the website has a large amount of data, the browser will generally occupy a large amount of CPU usage and memory during processing, causing the browser to lose response, and even cause the computer system to crash. When developing a website, if web performance is fully considered, this problem can be avoided to a large extent.

4. Ajax Web service vulnerability

Ajax is based on XML-based asynchronous transmission. XML messages in text format may have as much as twice the bandwidth of binary data. The more bandwidth required to transmit XML messages, the fewer resources are available to the system or application to perform other tasks. Such as executing complex algorithms to obtain desired results.

Excessively high bandwidth may lead to performance degradation caused by system overload. Excessive bandwidth will cause Ajax applications to output broken data because there are not enough resources to generate clean data. This means that the web services portal (of which the Ajax application is part) will expose broken data to other parts of the portal, resulting in malformed messages and over-parsing. If a threat actor exploited this vulnerability, it would cause the browser to crash.

On the other hand, frequent, smaller HTTP requests will increase the burden on back-end servers, load balancing programs and firewalls, resulting in excessive bandwidth and ultimately reduced performance. If the client stays on this page for a long time or does not close the browser, the browser's memory will continue to increase and will not be released, causing the client browser to crash.

To this end, when using Ajax more often, we have to consider accelerating Ajax applications through special hardware accelerators, optimization software, elimination of code redundancy, XML acceleration functions and solving interoperability issues. In addition, actively monitoring the traffic flow can continuously measure the network traffic performance of the Ajax application. By putting data into real-time logs, you can see where and when high packet loss and jitter events occur, why responses are slowing down, and how traffic flow performance can be improved by modifying application priorities.

5. Other reasons

In addition to the reasons mentioned above, there are many other reasons. Although some will not cause the browser to crash directly, they will also cause the website to be inaccessible, such as log files causing the disk to be full, web server C pointer error, The process lacks file descriptors, thread deadlocks, insufficient temporary tables in the database, and server overload, etc. Please refer to "The seven most common reasons for website crashes".

Summary

For visitors, if they log in to your website, the browser will crash immediately. I think this is intolerable to everyone. By summarizing "The reasons why the website crashes the browser 》, when we are engaged in website development and maintenance, we should try our best to avoid problems such as memory leaks, code errors, redundancy, and excessive data volume, and build a site with better performance.

PS: This article is summarized by Vicky . If reproduced, please indicate the source