पीवीएस-स्टूडियो के साथ एम्बी की जाँच

एम्बी Plex और कोडी के साथ काफी लोकप्रिय मीडिया सर्वर है। इस लेख में, हम स्थैतिक विश्लेषक PVS-Studio के साथ इसके स्रोत कोड में पाए गए बगों पर चर्चा करेंगे। परियोजना की आधिकारिक वेबसाइट पर "बिल्ट विथ रेस्परर" टिप्पणी विश्लेषण को और भी दिलचस्प बनाती है।

पी वी एस-स्टूडियो

पीवीएस-स्टूडियो 64-बिट विंडोज, लिनक्स और मैकओएस सिस्टम पर चलता है। यह C, C ++, C # और जावा में लिखे सॉफ्टवेयर के सोर्स कोड में बग्स का पता लगा सकता है।

विश्लेषण के तहत परियोजना

एम्बी एक मीडिया सर्वर है; इसका सोर्स कोड GitHub पर उपलब्ध है । यह उपयोगकर्ता को किसी भी डिवाइस पर अपनी मीडिया सामग्री (वीडियो, ऑडियो, फोटो) को स्ट्रीम और एक्सेस करने की अनुमति देता है। यहाँ परियोजना की आधिकारिक वेबसाइट के अनुसार एम्बी की विशेषताओं का एक संक्षिप्त सारांश है:

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

सबसे दिलचस्प कोड स्निपेट विश्लेषक द्वारा रिपोर्ट किया गया

PVS-Studio डायग्नोस्टिक संदेश: V3001 समान उप-अभिव्यक्तियाँ हैं c! = '' <'' बाईं और दाईं ओर '&&' ऑपरेटर। HttpListenerRequest.Managed.cs 49

internal void SetRequestLine(string req) { .... if ((ic >= 'A' && ic <= 'Z') || (ic > 32 && c < 127 && c != '(' && c != ')' && c != '<' && // <= c != '<' && c != '>' && c != '@' && c != ',' && c != ';' && // <= c != ':' && c != '\\' && c != '"' && c != '/' && c != '[' && c != ']' && c != '?' && c != '=' && c != '{' && c != '}')) continue; .... } 

एनालाइज़र ने डुप्लिकेट सब-डेप्रिसिएशन c = = '<' का पता लगाया है। एक व्याख्या यह है कि यह एक प्रोग्रामिंग गलती है और डेवलपर का अर्थ '<' के स्थान पर कुछ और लिखना है। एक और, अधिक संभावना स्पष्टीकरण, यह है कि दूसरा सबप्रेप्रेशन का मतलब वहां बिल्कुल नहीं था और इसे हटा दिया जाना चाहिए।

PVS-Studio नैदानिक ​​संदेश: V3001 समान उप-अभिव्यक्तियाँ हैं 'SmbConstants.AttrHidden' बाईं ओर और 'दाईं ओर' के लिए। ऑपरेटर। SmbComDelete.cs 29

 internal SmbComDelete(string fileName) { Path = fileName; Command = SmbComDelete; _searchAttributes = SmbConstants.AttrHidden | SmbConstants.AttrHidden | SmbConstants.AttrSystem; } 

एक और टाइपो जो डुप्लिकेट सबटेक्शंस के साथ करना है। साइड नोट के रूप में, एम्बी के स्रोत कोड में बहुत सारे मुद्दे हैं - असावधानी के कारण होने वाली गलतियाँ। मैं हालांकि डेवलपर्स को दोष नहीं दे रहा हूं; हम सभी कई बार अनुपस्थित-विचारशील हो सकते हैं ( उदाहरण , उदाहरण , उदाहरण ), और यही कारण है कि स्थैतिक विश्लेषण मौजूद है - हमें अपनी गलतियों से बचाने के लिए।

PVS- स्टूडियो डायग्नोस्टिक संदेश: V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। SqliteItemRepository.cs 5648

 private QueryResult<Tuple<BaseItem, ItemCounts>> GetItemValues(....) { .... if (typesToCount.Length == 0) { whereText += " And CleanName In (Select CleanValue from ItemValues where " + typeClause + " AND ItemId in (select guid from TypedBaseItems" + innerWhereText + "))"; } else { //whereText += " And itemTypes not null"; whereText += " And CleanName In (Select CleanValue from ItemValues where " + typeClause + " AND ItemId in (select guid from TypedBaseItems" + innerWhereText + "))"; } .... } 

और यह एक कॉपी-पेस्ट बग की तरह बहुत दिखता है क्योंकि अगर और किसी ब्लॉक में एक ही बॉडी है। यदि यह बाद के निष्पादन तर्क को प्रभावित नहीं करता है, तो टाइपटाउन सरणी के आकार की जाँच करने में क्या अच्छा है? यह कुछ ऐसा है जो केवल लेखक जानते हैं।

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3005 '_validProviderIds' चर को ही सौंपा गया है। BaseNfoParser.cs 77

 private Dictionary<string, string> _validProviderIds; .... public void Fetch(....) { .... _validProviderIds = _validProviderIds = new Dictionary<....>(....); .... } 

एक अन्य टाइपो, जिसके परिणामस्वरूप एक चर का अपना मान निर्दिष्ट किया जाता है। इस कोड को संशोधित करने की आवश्यकता है।

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3008 'चैप्टर' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 29, 28. शीर्षक ।cs 29

 public Title(uint titleNum) { ProgramChains = new List<ProgramChain>(); Chapters = new List<Chapter>(); Chapters = new List<Chapter>(); TitleNumber = titleNum; } 

यह असावधानी और टाइपो के बारे में है ... चैप्टर चर को दो बार एक मान दिया जाता है। निश्चित रूप से, यह डुप्लिकेट असाइनमेंट कोई नुकसान नहीं करने वाला है, लेकिन आप अभी भी अपने कोड में ऐसा कुछ नहीं चाहते हैं। इस पर कोई बात नहीं है, तो चलिए आगे बढ़ते हैं।

PVS- स्टूडियो डायग्नोस्टिक संदेश: V3013 यह अजीब है कि 'रीड' फ़ंक्शन का शरीर 'राइट' फ़ंक्शन (407, लाइन 415) के शरीर के बराबर है। BaseSqliteRepository.cs 407

 public static IDisposable Read(this ReaderWriterLockSlim obj) { return new WriteLockToken(obj); } public static IDisposable Write(this ReaderWriterLockSlim obj) { return new WriteLockToken(obj); } private sealed class WriteLockToken : IDisposable { private ReaderWriterLockSlim _sync; public WriteLockToken(ReaderWriterLockSlim sync) { _sync = sync; sync.EnterWriteLock(); } public void Dispose() { if (_sync != null) { _sync.ExitWriteLock(); _sync = null; } } } 

कार्य पढ़ें और लिखें में एक ही निकाय है, और यह वह है जो विश्लेषक हमें बता रहे हैं। EnterWriteLock विधि का उपयोग लेखन मोड में लॉक दर्ज करने के लिए किया जाता है। यदि आप रीड मोड में लॉक दर्ज करना चाहते हैं, तो EnterReadLock विधि का उपयोग करें, जो एक संसाधन को एक बार में कई थ्रेड्स द्वारा पढ़ने की अनुमति देता है।

डेवलपर्स को इस कोड की जांच करनी चाहिए क्योंकि इसमें बग होने की बहुत संभावना है - सभी अधिक इसलिए क्योंकि कोड में एक अप्रयुक्त वर्ग पाया गया है:

 private sealed class ReadLockToken : IDisposable { private ReaderWriterLockSlim _sync; public ReadLockToken(ReaderWriterLockSlim sync) { _sync = sync; sync.EnterReadLock(); } public void Dispose() { if (_sync != null) { _sync.ExitReadLock(); _sync = null; } } } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3021 समान सशर्त अभिव्यक्तियों के साथ दो 'यदि' कथन हैं। पहले 'if' स्टेटमेंट में मेथड रिटर्न होता है। इसका मतलब यह है कि दूसरा 'अगर' कथन संवेदनहीन है SkiaEncoder.cs 537

 public string EncodeImage(string inputPath, DateTime dateModified, string outputPath, bool autoOrient, ImageOrientation? orientation, int quality, ImageProcessingOptions options, ImageFormat selectedOutputFormat) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... } 

डेवलपर ने पहले चार पंक्तियों को क्लोन किया होगा, लेकिन इनपुटपथ से आउटपुटपाथ में चेक किए जा रहे चर का नाम बदलना भूल गया। ऐसी कई पंक्तियाँ हैं जहाँ पर आउटपुटपाउथ का उपयोग बिना किसी पूर्व जांच के किया जाता है, जिसका अर्थ है कि एक अपवाद फेंका जा सकता है।

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

• V3022 एक्सप्रेशन 'processUnsupportedFrame (फ़्रेम, CloseStatusCode.PolicyViolation, null)' हमेशा गलत होता है। WebSocket.cs 462
• V3022 अभिव्यक्ति 'processCloseFrame (फ्रेम)' हमेशा गलत है। WebSocket.cs 461
• V3022 अभिव्यक्ति 'फ्रेम। processCloseFrame (फ़्रेम): processUnsupportedFrame (फ़्रेम, CloseStatusCode.PolicyViolation, null) 'हमेशा गलत है। WebSocket.cs 460
• V3022 अभिव्यक्ति 'प्रक्रियापोंगफ्रेम (फ्रेम)' हमेशा सही होती है। WebSocket.cs 459
• V3022 अभिव्यक्ति 'processPingFrame (फ्रेम)' हमेशा सच होता है। WebSocket.cs 457
• V3022 अभिव्यक्ति 'processDataFrame (फ्रेम)' हमेशा सच होता है। WebSocket.cs 455
• V3022 अभिव्यक्ति हमेशा झूठी है। WebSocket.cs 448

 private bool processWebSocketFrame(WebSocketFrame frame) { return frame.IsCompressed && _compression == CompressionMethod.None ? processUnsupportedFrame(....) : frame.IsFragmented ? processFragmentedFrame(frame) : frame.IsData ? processDataFrame(frame) : frame.IsPing ? processPingFrame(frame) : frame.IsPong ? processPongFrame(frame) : frame.IsClose ? processCloseFrame(frame) : processUnsupportedFrame(....); } private bool processUnsupportedFrame(....) { processException(....); return false; } private bool processDataFrame(WebSocketFrame frame) { .... return true; } private bool processPingFrame(WebSocketFrame frame) { var mask = Mask.Unmask; return true; } private bool processPongFrame(WebSocketFrame frame) { _receivePong.Set(); return true; } private bool processCloseFrame(WebSocketFrame frame) { var payload = frame.PayloadData; close(payload, !payload.ContainsReservedCloseStatusCode, false); return false; } 

मैंने अब तक अपने पीवीएस-स्टूडियो टीम के साथियों की तुलना में कम परियोजनाओं की जाँच की है, और यह शायद यह बताता है कि मैंने पहले कभी 13 लाइनों का एक कोड स्निपेट क्यों नहीं देखा, जो एक ही बार में 7 चेतावनियों को ट्रिगर करेगा (यानी प्रति दो लाइनों में एक से अधिक चेतावनी)। इसलिए मैं इस मामले को लेख में शामिल कर रहा हूं। नीचे समस्या के टुकड़े का चरण-दर-चरण विश्लेषण है।

1. अभिव्यक्ति फ्रेम .sCompressed और& _compression == CompressionMethod.None का मूल्यांकन पहले किया जाता है। यदि यह सही है, तो ProcessUnsupportedFrame विधि किसी भी मामले में निष्पादित और गलत लौटेगी (यह पहली चेतावनी है)। यदि चेक गलत है , तो हम अगले एक पर जाते हैं।
2. मान फ़्रेम । IFragmented जाँच की जाती है। यहाँ कोई समस्या नहीं है।
3. मान फ़्रेम । IDData जाँच की है। यदि यह सही है, तो किसी भी स्थिति में processDataFrame विधि सही वापस आ जाएगी। यह दूसरी चेतावनी है।
4. मान फ़्रेम । IPPing जाँच की है। यदि यह सही है, तो ProcessPingFrame विधि सही वापस आ जाएगी। यह तीसरी चेतावनी है।
5. मान फ़्रेम । IPong जाँच की है। पिछले वाले के समान।
6. अंतिम एक: फ्रेम । processCloseFrame और processUnsupportedFrame किसी भी मामले में गलत है।

मुझे आशा है कि इसका पालन करना बहुत कठिन नहीं था। शेष उदाहरण उस जटिल नहीं हैं।

PVS- स्टूडियो डायग्नोस्टिक संदेश: V3085 नेस्टेड प्रकार में 'RtpHeaderBytes' फ़ील्ड का नाम अस्पष्ट है। बाहरी प्रकार में समरूप क्षेत्र समरूप नाम के साथ होता है। HdHomerunUdpStream.cs 200

 public class HdHomerunUdpStream : LiveStream, IDirectStreamProvider { .... private static int RtpHeaderBytes = 12; public class UdpClientStream : Stream { private static int RtpHeaderBytes = 12; private static int PacketSize = 1316; private readonly MediaBrowser.Model.Net.ISocket _udpClient; bool disposed; .... } .... } 

नेस्टेड क्लास UdpClientStream के पास एक फ़ील्ड है जिसका नाम एन्क्लोज़िंग क्लास HdHomerunUdpStream के फ़ील्ड के समान है। यह एक बग नहीं है, लेकिन यह सुनिश्चित करने के लिए कि यह सही है इस कोड को फिर से जांचने का एक अच्छा कारण है। समान नाम वाले चर होने से गलती से उनमें से एक के बजाय दूसरे का उपयोग करना आसान हो जाता है, जिसके परिणामस्वरूप प्रोग्राम का अप्रत्याशित व्यवहार होता है, जबकि कंपाइलर एक शब्द भी नहीं कहेगा।

पीवीएस-स्टूडियो नैदानिक ​​संदेश:

• एक प्रकार पर V3090 असुरक्षित लॉकिंग। एक प्रकार के सभी उदाहरणों में समान 'प्रकार' ऑब्जेक्ट होगा। Lmhosts.cs 49
• एक प्रकार पर V3090 असुरक्षित लॉकिंग। एक प्रकार के सभी उदाहरणों में समान 'प्रकार' ऑब्जेक्ट होगा। Lmhosts.cs 57

 public class Lmhosts { public static NbtAddress GetByName(string host) { lock (typeof(Lmhosts)) { return GetByName(new Name(host, 0x20, null)); } } internal static NbtAddress GetByName(Name name) { lock (typeof(Lmhosts)) { .... } } } 

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

आदर्श रूप से, आपको लॉकिंग के लिए एक निजी क्षेत्र का उपयोग करना चाहिए, उदाहरण के लिए:

 private Object locker = new Object(); public static NbtAddress GetByName(string host) { lock (locker) { return GetByName(new Name(host, 0x20, null)); } } 

पीवीएस-स्टूडियो डायग्नोस्टिक मैसेज: V3142 Unreacheble कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। HdHomerunHost.cs 621

 protected override async Task<ILiveStream> GetChannelStream(....) { .... var enableHttpStream = true; if (enableHttpStream) { mediaSource.Protocol = MediaProtocol.Http; var httpUrl = channelInfo.Path; // If raw was used, the tuner doesn't support params if (!string.IsNullOrWhiteSpace(profile) && !string.Equals(profile, "native", StringComparison.OrdinalIgnoreCase)) { httpUrl += "?transcode=" + profile; } mediaSource.Path = httpUrl; return new SharedHttpStream(....); } return new HdHomerunUdpStream(....); } 

विश्लेषक का कहना है कि इस स्निपेट में अंतिम पंक्ति कभी भी निष्पादित नहीं होगी। और चर enableHttpStream घोषित करने का क्या उद्देश्य है, इसे सही रूप में निर्दिष्ट करना, और बाद में सही तरीके से जांचना?

शायद यह कोड केवल बेमानी है, लेकिन इसे वैसे भी संशोधित करने की आवश्यकता है।

पीवीएस-स्टूडियो डायग्नोस्टिक मैसेज: V3083 इवेंट 'रीफ्रेशस्टार्टेड' का अनसेफ इनवोकेशन, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। ProviderManager.cs 943

 public void OnRefreshStart(BaseItem item) { .... if (RefreshStarted != null) { RefreshStarted(this, new GenericEventArgs<BaseItem>(item)); } } 

विश्लेषक हमें रीफ़्रेशस्टार्ट किए गए ईवेंट हैंडलर के संभावित असुरक्षित कॉल के बारे में चेतावनी देता है।

आइए जानें कि यह कॉल असुरक्षित क्यों है। मान लीजिए कि इस घटना को किसी अन्य थ्रेड से अशक्त हो जाता है, तो घटना के लिए अशक्त के लिए घटना की जाँच करने और अगर स्टेटमेंट में इवेंट हैंडलर को कॉल करने के बीच। यदि कोई ग्राहक नहीं बचा है, तो RefreshStarted ईवेंट शून्य हो जाएगा, लेकिन उस थ्रेड में जहां नल चेक पहले ही पास हो चुका है, कॉल को वैसे भी निष्पादित किया जाएगा:

 RefreshStarted(this, new GenericEventArgs<BaseItem>(item)); 

यह एक NullReferenceException को फेंकने में परिणाम देगा।

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3029 एक दूसरे के साथ स्थित 'अगर' कथन की सशर्त अभिव्यक्तियाँ समान हैं। चेक लाइनें: 142, 152. लोकलइमेजप्रोवाइडर.केएस 142

 private void PopulateImages(....) { .... // Logo if (!isEpisode && !isSong && !isPerson) { added = AddImage(....); if (!added) { added = AddImage(....); } } // Art if (!isEpisode && !isSong && !isPerson) { AddImage(....); } .... } 

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

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3041 अभिव्यक्ति को 'इंट' टाइप से 'डबल' टाइप किया गया। एक आंशिक भाग के नुकसान से बचने के लिए एक स्पष्ट प्रकार के कलाकारों का उपयोग करने पर विचार करें। एक उदाहरण: डबल ए = (डबल) (एक्स) / वाई ;; LiveTvManager.cs 1085

 private async Task RefreshChannelsInternal(....) { .... double progressPerService = _services.Length == 0 ? 0 : 1 / _services.Length; .... } 

इस कोड में एक पूर्णांक विभाजन होता है, जिसके परिणामस्वरूप मान एक फ़्लोटिंग-पॉइंट प्रकार पर डाला जाता है, जो करने के लिए एक सही चीज़ नहीं दिखता है।

दरअसल, progressPerService वैरिएबल का मान 1.0 होगा तभी होगा जब _services.Length = 1 हो । _Services.Length के किसी भी अन्य मूल्य के साथ , परिणाम 0.0 होगा।

मुझे लगता है कि इसके बजाय जो लिखा जाना चाहिए वह निम्नलिखित है:

 double progressPerService = _services.Length == 0 ? 0 : (double)1 / _services.Length; 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3050 संभवतः एक गलत HTML है। </ U> समापन टैग का सामना करना पड़ा, जबकि </ i> टैग अपेक्षित था। SrtParserTests.cs 64

 public void TestParse() { var expectedSubs = new SubtitleTrackInfo { TrackEvents = new SubtitleTrackEvent[] { .... new SubtitleTrackEvent { Id = "6", StartPositionTicks = 330000000, EndPositionTicks = 339990000, Text = "This contains nested <b>bold, <i>italic, <u>underline</u> and <s>strike-through</s></u></i></b> HTML tags" }, .... } }; } 

इस लाइन पर ध्यान दें:

 <u>underline</u> 

इसमें पहले से ही एक बंद टैग </ u> है ।
फिर हम निम्नलिखित पाठ देखते हैं:

 </s></u></i></b> HTML tags" 

यहां एक अतिरिक्त समापन टैग </ u> है, जो कि विश्लेषक बताता है।

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3051 एक अत्यधिक प्रकार की जांच। ऑब्जेक्ट पहले से ही 'अपवाद' प्रकार का है। SmbFileInputStream.cs 107

 protected internal virtual IOException SeToIoe(SmbException se) { IOException ioe = se; Exception root = se.GetRootCause(); if (root is TransportException) { ioe = (TransportException)root; root = ((TransportException)ioe).GetRootCause(); } if (root is Exception) { ioe = new IOException(root.Message); ioe.InitCause(root); } return ioe; } 

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

निष्कर्ष

एम्बी के डेवलपर्स ने हर तरह से शानदार काम किया है (परियोजना 215,539 एलओसी लंबी है, जिसमें से 4.6% टिप्पणियां हैं)। उन्होंने अच्छा किया, मेरा मतलब है। लेकिन पीवीएस-स्टूडियो भी प्रशंसा के पात्र हैं: इसने 113 उच्च- स्तर , 213 मध्यम-स्तर और 112 निम्न-स्तर की चेतावनी का उत्पादन किया। उनमें से कुछ गलत सकारात्मक थे, लेकिन अधिकांश बग का उल्लेख यहां नहीं किया गया था क्योंकि वे बहुत ही समान थे। उदाहरण के लिए, V3022 डायग्नोस्टिक (हमेशा झूठी / सच्ची स्थिति) अकेले 106 बार ट्रिगर किया गया था। बेशक, मैं झूठी सकारात्मक चीजों को छान सकता था और बाकी को लेख में शामिल कर सकता था, लेकिन यह पढ़ने के लिए बहुत उबाऊ हो जाता।

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