पीवीएस-स्टूडियो विश्लेषक के साथ एम्बी स्रोत कोड विश्लेषण

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

पीवीएस-स्टूडियो कोड विश्लेषक

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

अंकेक्षित परियोजना

Emby एक मीडिया सर्वर है जिसका सोर्स कोड 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-Studio चेतावनी: 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 + "))"; } .... } 

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

PVS-Studio चेतावनी: V3005 '_validProviderIds' चर अपने आप को सौंपा गया है। BaseNfoParser.cs 77

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

फिर से, एक टाइपो, जिसने स्वयं को एक चर का असाइनमेंट दिया। यह कोड के इस टुकड़े को रीचेक करने के लायक है।

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

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

Inattention और typos, फिर से ... चर अध्याय दो बार एक मान असाइन किया गया है। यह स्पष्ट है कि इस अतिरिक्त कोड से कुछ भी बुरा होने का खतरा नहीं है, लेकिन फिर भी। इस उदाहरण पर विचार करने का कोई मतलब नहीं है, चलो आगे बढ़ते हैं।

PVS-Studio चेतावनी: V3013 यह विचित्र है कि 'Read' फंक्शन का शरीर 'Write' फंक्शन (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; } } } 

एनालाइजर चेतावनी पाठ द्वारा सबूत के रूप में पढ़ें और लिखें कार्यों के निकाय एक दूसरे के बिल्कुल समान हैं। Enter मोड में लॉक दर्ज करने के लिए 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"); } .... } 

यहाँ, जाहिरा तौर पर, डेवलपर ने पहले चार पंक्तियों की प्रतिलिपि बनाई, लेकिन इनपुटपथ से आउटपुटपथ पर परीक्षण किए जा रहे चर को बदलना भूल गया। कोड में कई पंक्तियाँ हैं जो null की जाँच के बिना 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 लाइनों पर 13 विश्लेषक चेतावनी जारी की जाती हैं (हर दूसरी पंक्ति से थोड़ा अधिक)। इसलिए, मेरा मानना ​​है कि यह कोड लेख में शामिल किए जाने के योग्य है। इसके बाद, मैं लिखूंगा कि विश्लेषक विशेष रूप से क्या शपथ लेता है।

1. सबसे पहले, अभिव्यक्ति फ्रेम। Ssppressed && _compression == CompressionMethod.None को माना जाता है और, यदि अभिव्यक्ति सही है, तो ProcessUnsupportedFrame विधि निष्पादित की जाएगी, जो किसी भी स्थिति में गलत है (इसलिए विश्लेषक की पहली चेतावनी)। यदि यह गलत था, तो अगले बिंदु पर जाएं।
2. इसके बाद, फ़्रेम का मान। एसफ़्रेग्मेंटेड की जाँच की जाती है । कोई समस्या नहीं है, तो चलो आगे बढ़ते हैं।
3. यहाँ फ्रेम की वैल्यू .DData की जाँच की जाती है । यदि सही है, तो processDataFrame विधि किसी भी तरह से सही हो जाएगी। इसलिए दूसरा विश्लेषक चेतावनी।
4. फिर हम फ्रेम की जांच करते हैं । सच - processPingFrame सही लौटेगा। यह तीसरा विश्लेषक चेतावनी है।
5. हम फ्रेम को देखते हैं । सब कुछ पिछले एक के समान है।
6. और आखिरी एक: फ्रेम । processCloseFrame और processUnsupportedFrame किसी भी मामले में गलत है ।

मुझे उम्मीद है कि मैंने आपको बोर नहीं किया। यह आगे सरल होगा।

PVS-Studio चेतावनी: 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 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। 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 चर को सही पर सेट करता है और फिर तुरंत इस कथन में इस चर की जांच करता है?

शायद यह कोड केवल बेमानी है। किसी भी मामले में, यह दोहरी जांच के लायक है।

PVS-Studio चेतावनी: V3083 'RefreshStarted', NullReferenceException घटना का असुरक्षित आह्वान संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। ProviderManager.cs 943

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

यह विधि RefreshStarted ईवेंट हैंडलर के लिए संभावित असुरक्षित कॉल का उपयोग करती है, जैसा कि विश्लेषक इंगित करता है।

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

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

यह एक NullReferenceException को फेंक देगा।

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

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

एक दूसरे के बगल में कोड के इस टुकड़े में दो हैं यदि समान शर्तों के साथ बयान । अगर बयानों के निकाय अलग हैं। यह कहना मुश्किल है कि यह एक गलती है या अनावश्यक कोड। शायद सब कुछ ठीक है और लेखक केवल दो अलग-अलग क्रियाओं को तार्किक रूप से अलग करना चाहता था, जिनमें से एक निश्चित "लोगो" के साथ जुड़ा हुआ है, और दूसरा एक निश्चित "कला" के साथ।

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

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

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

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

जाहिर है, यह यहाँ लिखा जाना चाहिए:

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

PVS-Studio चेतावनी: 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> अतिशयोक्तिपूर्ण है, जैसा कि विश्लेषक इंगित करता है।
चेतावनी पीवीएस-स्टूडियो: वी 3051 एक अत्यधिक प्रकार की जांच। ऑब्जेक्ट पहले से ही 'अपवाद' प्रकार का है। 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 टुकड़े किए। आप निश्चित रूप से जांच सकते हैं कि उनमें से कौन सा हिस्सा गलत सकारात्मक था, और बाकी लेख में जोड़ें, लेकिन इससे बहुत उबाऊ पाठ होगा जो कोई भी नहीं पढ़ेगा।

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

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