क्या कोई जानता है कि क्या "Aw Snap!" का कारण निर्धारित करने का कोई व्यावहारिक तरीका है। संदेश जो कभी-कभी Google Chrome पर दिखाई देता है? क्या Chrome में कोई त्रुटि लॉग है जिसका मैं उल्लेख कर सकता हूं? मुझे संदेह है कि यह समस्या कोड में एक पुनरावर्ती लूप के कारण होती है जो तब सभी मेमोरी को निगल रही है? क्या कोई तरीका है जिससे मैं इसकी पुष्टि कर सकूं?
जवाबों:
यहाँ देखें, स्पष्टीकरण देखें: क्रोम में साधारण लॉगिंग के लिए, आप कोशिश कर सकते हैं:
Chrome की लॉगिंग सुविधा का उपयोग करें :
लॉगिंग को सक्षम करने के लिए, इन कमांड लाइन झंडे के साथ क्रोम लॉन्च करें:
--enable-logging --v=1
Chrome की उपयोगकर्ता डेटा निर्देशिकाchrome_debug.log में फ़ाइल में आउटपुट सहेजा जाएगा ।
लॉग फ़ाइल का स्थान CHROME_LOG_FILEपर्यावरण चर द्वारा ओवरराइड किया जा सकता है ।
झंडे की पूरी सूची के लिए, जांचें: Google Chrome कमांड लाइन स्विच ।
या जावास्क्रिप्ट कंसोल का उपयोग करें :
प्रेस Ctrl+ Shift+ J(विंडोज / लिनक्स) या Cmd+ Option+ J(मैक)।
ऑफिशियल क्रोम डेवलपर्स ट्विटर अकाउंट एक वेबसाइट से जुड़ा हुआ है जो आपको "Aw Snap" पेज डीबग करने में मदद करता है: http://www.chromium.org/for-testers/enable-log
इन झंडे के साथ क्रोम लॉन्च करने की सिफारिश की गई है:
--enable-logging --v=1
यदि आप ऐसा करते हैं, तो आप chrome_debug.logक्रोम के उपयोगकर्ता डेटा निर्देशिका (पेरेंट डायरेक्टरी में Default/) या बाइनरी बिल्ड फ़ोल्डर ( out\Debug) में डिबग बिल्ड का उपयोग कर रहे हैं , तो फ़ाइल से क्रैश लॉग को पकड़ सकते हैं ।
--enable-logging --v=1 को स्वीकार किए गए उत्तर को संपादित करने से बहुत पहले उल्लेख किया गया था।
द अजी, स्नैप! पृष्ठ आमतौर पर प्रक्रिया विभाजन दोष दुर्घटना से संबंधित है जो सॉफ्टवेयर बग से संबंधित हो सकता है । कारण निर्धारित करने के लिए, आप लॉगिंग को सक्षम कर सकते हैं (जैसा कि अन्य उत्तरों में सुझाया गया है) या कोर डंप फ़ाइल ( मैकओएस , लिनक्स , उदाहरण के लिए उबंटू ) के बैकट्रेस का विश्लेषण कर सकते हैं ।
यदि आपको कारण पता नहीं है (जैसे स्टैक ट्रेस में केवल मेमोरी एड्रेस होते हैं), तो आप Chrome बग ट्रैकिंग सिस्टम पर एक नया समर्थन टिकट बना सकते हैं (या पहले से ही कोई है या नहीं) इसकी दोबारा जांच करें। रिपोर्टिंग करते समय, आपको chrome://crashes/पेज पर जाकर क्रैश आईडी को अपलोड करना चाहिए और शामिल करना चाहिए , इसलिए क्रोम अनुरक्षकों द्वारा मेमोरी एड्रेस का अनुवाद डिबग प्रतीकों में किया जा सकता है।
वैकल्पिक रूप से आप अपने आप को क्रैश डंप डिकोड कर सकते हैं ।
यह भी देखें: Google Chrome क्रैश डंप कहां स्थित है?
ऊपर सरलीकृत करने के लिए, यहां मुख्य कारण हैं कि पृष्ठ दुर्घटनाग्रस्त क्यों हो सकता है:
आपने बग ढूंढ लिया है (या तो वेबसाइट पर या वेब ब्राउजर इट-सेल्फ के साथ)।
वेबसाइट बग
उदाहरण: जावास्क्रिप्ट वीएम अधिकतम आवंटित मेमोरी (आउट-ऑफ-मेमोरी क्रैश) तक पहुंच गया।
जाँचने के लिए, DevTools चलाएं और मेमोरी टैब जांचें । यदि ऐसा है, तो संभावित आउट-ऑफ-मेमोरी क्रैश (जैसे अंक 810015 ) से ठीक पहले कोड को स्वचालित रूप से विराम देना चाहिए । यदि हां, तो वेबसाइट के मालिक को समस्या की रिपोर्ट करें, या बग को खोजने के लिए जेएस कोड को प्रोफाइल करें।
ब्राउज़र बग
आप अपने सिस्टम की अधिकतम खुली फाइलों तक पहुँच गए हैं (देखें: # 787381 )।
Linux / Unix / macOS पर, यह सत्यापित करने के लिए कि रन:
sysctl -a | grep files
और जाँच करें कि क्या kern.num_filesसीमा तक पहुँच गया है kern.maxfiles।
यदि ऐसा है, तो निम्न कमांड चलाकर सीमा बढ़ाएँ:
sysctl -w kern.maxfiles=20480
which launchctl && launchctl limit maxfiles 65536 unlimited
which ulimit && ulimit -c unlimited
आपके पास कुछ मैलवेयर / वायरस हो सकते हैं जो क्रैश होने के कारण आपकी Chrome फ़ाइलों को बदल देते हैं।
memtest) चलाएं ।Chrome से लॉग प्रदर्शित करने के लिए, चलाएँ:
log stream --level debug --predicate 'processImagePath contains "Google"'
या कंसोल ऐप चलाकर , जहां आप किसी भी क्रैश डंप (या चेक इन ~/Library/Logs/DiagnosticReports) के लिए भी जांच कर सकते हैं । देखें: Chrome में "Aw, Snap!" डीबग त्रुटि
यदि उपरोक्त में से कोई भी मदद नहीं करता है, तो आप स्रोत से क्रोम संकलित करने पर विचार कर सकते हैं (एक लंबा समय लगता है), फिर सीधे टर्मिनल से चलाएं। उसके बाद, प्रत्येक "Aw, Snap!" एरर को फुल स्टैक ट्रेस द्वारा फॉलो किया जाना चाहिए जिसमें फ़ंक्शंस और लाइन इन सोर्स कोड फ़ाइल होती है जहाँ यह हुआ था।