डेजर्ट लायंस एंड इंट्रोस्पेक्शन

शायद, हैबर के लगभग सभी निवासियों को पता है कि एक द्विबीजपत्री क्या है और रेगिस्तान में एक शेर को पकड़ने के लिए इसका उपयोग कैसे किया जाता है। कार्यक्रमों में त्रुटियां भी एक द्विभाजन के साथ पकड़ी जा सकती हैं, विशेष रूप से समझदार नैदानिक ​​जानकारी के अभाव में।



PHP / Laravel में अपने प्रोजेक्ट को डीबग करने के बाद, मैंने ब्राउज़र में यह त्रुटि देखी:



यह, कम से कम, अजीब था, क्योंकि, RFC 2616 में वर्णन द्वारा निर्णय लेने पर, 502 त्रुटि का अर्थ है कि "सर्वर, जो एक गेटवे या प्रॉक्सी के रूप में कार्य करता है, को अपस्ट्रीम सर्वर से गलत प्रतिक्रिया मिली।" मेरे मामले में, कोई गेटवे नहीं थे, वेब सर्वर और ब्राउज़र के बीच कोई प्रॉक्सी नहीं था, वेब सर्वर वर्चुअलबॉक्स के तहत चल रहा था, और बिना किसी मध्यस्थ के सीधे वेब सामग्री वितरित कर रहा था। नग्नेक्स लॉग में यह था:

2018/06/20 13:42:41 [error] 2791#2791: *2206 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.10.1, server: colg.test, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock:", host: "colg.test"

502 त्रुटि (आरएफसी के मूल अंग्रेजी संस्करण में "अपस्ट्रीम सर्वर") के वर्णन में "अपस्ट्रीम सर्वर" शब्द ने ब्राउज़र से नग्नेक्स के लिए अनुरोध पथ पर कुछ अतिरिक्त नेटवर्क सर्वर का सुझाव दिया, लेकिन, जाहिर है, इस मामले में, संदेश में उल्लेख किया गया है। PHP-FPM मॉड्यूल, सर्वर प्रोग्राम होने के नाते, यह बहुत अपस्ट्रीम सर्वर के रूप में कार्य करता है। PHP के लॉग में, यह था:

[20-Jun-2018 13:42:41] WARNING: [pool www] child 26098 exited on signal 11 (SIGSEGV - core dumped) after 102247.908379 seconds from start

अब यह स्पष्ट हो गया था कि समस्या कहाँ है, लेकिन इसका कारण स्पष्ट नहीं था। PHP केवल कोर डंप में गिरा, PHP प्रोग्राम की व्याख्या में किस बिंदु पर कोई त्रुटि हुई, यह प्रदर्शित नहीं किया गया। तो रेगिस्तान में एक शेर को पकड़ने का समय आ गया है - ऐसे मामलों में डाइकोटॉमी द्वारा डिबगिंग की मेरी पसंदीदा विधि का उपयोग करने के लिए। टिप्पणियों में आपत्तियों पर विचार करते हुए, मैं ध्यान देता हूं कि यहां एक डीबगर का उपयोग किया जा सकता है, उदाहरण के लिए, एक ही एक्सडेबग, लेकिन डायकोटॉमी अधिक दिलचस्प था। इसके अलावा, XDebug की बारी आएगी।

इसलिए, वेब अनुरोध को संसाधित करने के तरीके में, मैंने प्रोग्राम के आगे पूरा होने के साथ सबसे सरल नैदानिक ​​आउटपुट निर्धारित किया है, यह सुनिश्चित करने के लिए कि इसकी स्थापना के स्थान पर कोई त्रुटि नहीं होती है:

 echo “I am here”; die(); 

अब बुरा पृष्ठ इस तरह दिखता है:



ऊपर लिखी कमांड रखने के बाद, शुरुआत में, और फिर वेब रिक्वेस्ट प्रोसेसिंग पाथ के अंत में, मुझे पता चला कि एक त्रुटि (जो उस पर संदेह करेगी!) इन दो बिंदुओं के बीच कहीं होती है। वेब अनुरोध पथ के मध्य में निदान सेट करने के बाद, मुझे पता चला कि त्रुटि अंत में कहीं दिखाई देती है। इस तरह के पुनरावृत्तियों के एक जोड़े के बाद, मुझे एहसास हुआ कि त्रुटि लारवेल एमवीसी वास्तुकला के नियंत्रक में ही नहीं होती है, लेकिन पहले से ही इसके बाहर निकलने पर, जब इस दृश्य में, जो कि यहां सबसे सरल है, इस प्रतिपादन में:

 @extends('layouts.app') @section('content') <div> <div class="panel-heading">Myservice</div> <div class="panel-body"></div> </div> @endsection 

जैसा कि आप देख सकते हैं, व्यू टेम्प्लेट में PHP कोड नहीं होता है (Laravel टेम्पलेट इंजन आपको देखने में PHP कोड का उपयोग करने की अनुमति देता है), और समस्याएं निश्चित रूप से यहां नहीं हैं। लेकिन ऊपर हम देखते हैं कि यह दृश्य लेआउट.अप टेम्पलेट को विरासत में मिला है, इसलिए वहां देखें। यह पहले से ही अधिक जटिल है: सेवा के सभी पृष्ठों के लिए नेविगेशन तत्व, लॉगिन फ़ॉर्म और अन्य चीजें सामान्य हैं। वहां होने वाली हर चीज को स्वीकार करते हुए, मैं केवल एक पंक्ति दूंगा, जिसके कारण एक विफलता उत्पन्न हुई, यह सभी एक ही डाइकोमोमी पाया गया। यहाँ लाइन है:

 <script> window.bkConst = {!! (new App\Src\Helpers\UtilsHelper())->loadBackendConstantsAsJSData() !!}; </script> 

यहाँ, बस व्यू टेम्प्लेट के कोड में, PHP का उपयोग किया गया था। यह मेरा "आकर्षण" था - बैकेंड स्थिरांक की व्युत्पत्ति, जेएस-कोड के रूप में, डीआरवाई सिद्धांत के नाम पर, दृश्यपटल पर उपयोग के लिए। LoadBackendConstantsAsJSData विधि कई वर्गों को सामने वाले पर आवश्यक स्थिरांक के साथ सूचीबद्ध करती है। AddClassConstants मेथड में उनके द्वारा उपयोग की गई त्रुटि हुई, जहाँ PHP आत्मनिरीक्षण का उपयोग कक्षा के सहकर्मियों की सूची प्राप्त करने के लिए किया गया था:

 /** * add all class constants to resulted JSON * @param string $classFullName */ private function addClassConstants(string $classFullName, array &$constantsArray) { $r = new ReflectionClass($classFullName); $result = []; $className = $r->getShortName(); $classConstants = $r->getConstants(); foreach($classConstants as $name => $value) { if (is_array($value) || is_object($value)) { continue; } $result["$className::$name"] = $value; } $constantsArray = array_merge($constantsArray, $result); } 

स्थिरांक के साथ वर्गों के बीच खोज करने के बाद इस विधि को पारित कर दिया, यह पता चला है कि सब कुछ के लिए कारण - स्थिरांक के साथ इस वर्ग - बाकी एपीआई तरीकों के लिए रास्ता है।

 class APIPath { const API_BASE_PATH = '/api/v1'; const DATA_API = self::API_BASE_PATH . "/data"; ... const DATA_ADDITIONAL_API = DATA_API . "/additional"; } 

इसमें काफी कुछ लाइनें हैं, और सही को खोजने के लिए, एक डाइकोटॉमी फिर से उपयोगी थी। अब, मुझे आशा है कि सभी ने देखा कि स्व :: निरंतर नाम DATA_API के सामने स्थिर की परिभाषा में गायब है। इसे उसके सही स्थान पर जोड़ने के बाद, सब कुछ काम कर गया।

यह तय करने के बाद कि समस्या आत्मनिरीक्षण तंत्र में है, मैंने बग को पुन: पेश करने के लिए एक न्यूनतम उदाहरण लिखना शुरू किया:

 class SomeConstants { const SOME_CONSTANT = SOME_NONSENSE; } $r = new \ReflectionClass(SomeConstants::class); $r->getConstants(); 

हालाँकि, इस स्क्रिप्ट को चलाने के दौरान, PHP क्रैश नहीं होने वाली थी, बल्कि पूरी तरह से चेतावनी जारी की थी।

PHP Warning: Use of undefined constant SOME_NONSENSE - assumed 'SOME_NONSENSE' (this will throw an Error in a future version of PHP) in /home/vagrant/code/colg/_tmp/1.php on line 17

इस बिंदु पर, मैं पहले से ही आश्वस्त था कि समस्या न केवल साइट को लोड करते समय प्रकट होती है, बल्कि कमांड लाइन के माध्यम से ऊपर लिखे कोड को निष्पादित करते समय भी होती है। रनटाइम और न्यूनतम स्क्रिप्ट के बीच एकमात्र अंतर लारवेल संदर्भ की उपस्थिति था: समस्या कोड इसकी कारीगर उपयोगिता के माध्यम से चलाया गया था। इसलिए लारवेल के तहत किसी तरह का अंतर था। यह समझने के लिए कि यह क्या है, डिबगर का उपयोग करने का समय है। Xdebug के तहत कोड को चलाने पर, मैंने देखा कि रिफ्लेक्शनक्लास को कॉल करने के बाद दुर्घटना पहले से ही होती है :: getConstants विधि, Illuminate \ Foundation \ Bootstrap \ HandleException :: handleError विधि में, जो बहुत ही सरल है:

 public function handleError($level, $message, $file = '', $line = 0, $context = []) { if (error_reporting() & $level) { throw new ErrorException($message, 0, $level, $file, $line); } } 

निष्पादन का धागा एक अपवाद को फेंकने के बाद वहां मिला, जिसमें से निरंतरता का वर्णन करने में बहुत त्रुटि के कारण यह शुरू हुआ था, और एक त्रुटि अपवाद को फेंकने की कोशिश करते समय PHP दुर्घटनाग्रस्त हो गया। अपवाद हैंडलर में एक अपवाद ... मैंने तुरंत प्रसिद्ध डबल फॉल्ट को याद किया। तो, विफलता का कारण बनने के लिए, आपको लारवेल के समान अपवाद हैंडलर स्थापित करने की आवश्यकता है। कोड में थोड़ा अधिक सिर्फ बूटस्ट्रैप विधि थी जिसने ऐसा किया:

अब, अंतिम न्यूनतम उदाहरण इस तरह देखा गया:

 <?php class SomeConstants { const SOME_CONSTANT = SOME_NONSENSE; } function handleError() { throw new ErrorException(); } set_error_handler('handleError'); set_exception_handler('handleError'); $r = new \ReflectionClass(SomeConstants::class); $r->getConstants(); 

और इसके लॉन्च ने PHP संस्करण 7.2.4 इंटरप्रेटर को कोर डंप में तेजी से पैक किया।

ऐसा लगता है कि यहां एक अनंत पुनरावृत्ति है - जब मूल त्रुटि से एक अपवाद को संभालते हैं, तो निम्न अपवाद को handleException में फेंक दिया जाता है, फिर से handleException में संभाला जाता है, और इसी तरह अनन्तता के लिए। इसके अलावा, विफलता को पुन: उत्पन्न करने के लिए, आपको त्रुटि_हैंडलर और अपवाद_हैंडलर दोनों सेट करने की आवश्यकता है, यदि उनमें से केवल एक सेट है, तो समस्या उत्पन्न नहीं होती है। यह भी केवल एक अपवाद को फेंकने में विफल रहा, एक त्रुटि को फेंकने के बजाय, ऐसा लगता है कि यह काफी सामान्य पुनरावृत्ति नहीं है, लेकिन एक परिपत्र निर्भरता जैसी कुछ है।

उसके बाद, मैंने PHP के विभिन्न संस्करणों (धन्यवाद, डॉकर!) के तहत एक समस्या के लिए जाँच की। यह पता चला कि विफलता केवल स्वयं प्रकट होती है, PHP 7.1 के संस्करण से शुरू होती है, PHP के पूर्व संस्करण सही ढंग से काम करते हैं - वे बिना किसी त्रुटि के अपवाद अपवाद की शपथ लेते हैं।

इस सब से क्या निष्कर्ष निकाला जा सकता है?

1. डाइकोटोटॉमी द्वारा डिबगिंग, हालांकि यह डिबगिंग की एक एंटीडिलुवियन विधि है, लेकिन कभी-कभी यह आवश्यक हो सकता है, विशेष रूप से नैदानिक ​​जानकारी की कमी की स्थितियों में
2. मेरी राय में, 502 त्रुटियां अकल्पनीय हैं, दोनों संदेश इसके बारे में ("बैड गेटवे") और आरएफसी में इसके डिकोडिंग "अपस्ट्रीम सर्वर से गलत प्रतिक्रिया" के बारे में। यद्यपि, यदि आप वेब सर्वर से जुड़े मॉड्यूल को सर्वर प्रोग्राम मानते हैं, तो आप RFC में त्रुटि डिकोडिंग के अर्थ को समझ सकते हैं। हालाँकि, मान लीजिए कि प्रलेखन में समान PHP-FPM को एक मॉड्यूल कहा जाता है, न कि सर्वर।
3. स्थैतिक विश्लेषक ड्राइव, यह तुरंत निरंतर के विवरण में एक त्रुटि की रिपोर्ट करेगा। लेकिन तब बग को पकड़ा नहीं जाएगा।

मुझे इस पर समाप्त करने के लिए, आपका ध्यान देने के लिए धन्यवाद!

Bagreport - भेजा गया ।
UPD: बग ठीक हो गया है । कोड को देखते हुए, यह फिर भी प्रतिबिंब तंत्र में समाप्त हो गया - रिफ्लेक्शनक्लास की त्रुटि से निपटने में :: getCststore विधि