Stlink: st-util को LIBUSB_ERROR_NO_DEVICE पर बाहर निकलना चाहिए

मुझे लगता है कि stlink इस बिंदु पर समाप्त होना चाहिए: https://github.com/texane/stlink/blob/df3c2b02867db03fb82f6faaad71300398965e85/src/usb.c#L54

मुझे लगता है कि stlink इस बिंदु पर समाप्त होना चाहिए:

https://github.com/texane/stlink/blob/df3c2b02867db03fb82f6faaad71300398965e85/src/usb.c#L54

हाँ, मुझे लगता है कि आप सही हैं, libusb के लिए एक कॉल की उचित जांच की जानी चाहिए। आप चाहें तो पैचअप कर पीआर भेज सकते हैं। यह usb.c फ़ाइल में अन्य कॉलों के लिए libusb के लिए भी किया जाना चाहिए। रिपोर्टिंग के लिए धन्यवाद!

आप चाहें तो पैचअप कर पीआर भेज सकते हैं।

मुझे अच्छा लगेगा। हालांकि, मुझे यकीन नहीं है कि मैं परियोजना संरचना को समझता हूं इसलिए एक सादा exit(1) यहां पर्याप्त है या नहीं।

यह usb.c फ़ाइल में अन्य कॉलों के लिए libusb के लिए भी किया जाना चाहिए।

शायद मैं इसे अच्छी तरह से नहीं समझ पा रहा हूँ। क्या आपका मतलब है " send_recv -1 लौटने पर एप्लिकेशन को समाप्त कर दें?

मैंने पीआर में एक टिप्पणी रखी है, ऐसे और भी स्थान हैं जहां यह गलत हो सकता है जब libusb को कॉल किया जाता है।

परियोजना निम्नलिखित तरीके से आयोजित की जाती है:

• libstlink (usb.c इसका हिस्सा है और इसे कभी भी लाइब्रेरी में एक्जिट का उपयोग नहीं करना चाहिए) लाइब्रेरी की फाइलें src फोल्डर में स्थित होती हैं, सबसे महत्वपूर्ण है usb.c और common.c (और निश्चित रूप से flash_loader.c)
• st-util src/gdbserver में स्थित है
• st-info src/tools/info.c . में स्थित है
• st-flash src/tools/flash.c . में स्थित है

मुझे लगता है कि यह #888 और #445 से संबंधित हो सकता है।
@ceremcem और @rewolff : इस पर एक साथ चर्चा करने के विचार के बारे में क्या?

@chenguokai : क्या आपके पास यहां आगे बढ़ने के बारे में कोई विचार है?

इस मामले को पुन: पेश नहीं कर सकता।
मैंने अपने macOS मशीन पर प्रक्रिया का पालन किया। त्रुटि संदेश प्रकट होता है, लेकिन किसी भी मृत लूप में प्रवेश करने का कोई संकेत नहीं है।

संपादित करें: मैंने main फ़ंक्शन पर ब्रेकपॉइंट सेट करने और सेंट-लिंक को अनप्लग करने के बाद n आदेश जारी किया

एक समस्या मौजूद है कि प्रोग्राम को पैकेट भेजने या प्राप्त करने के लिए असीमित रूप से पुनः प्रयास करने के बजाय बाहर निकलना चाहिए।

https://github.com/texane/stlink/blob/0082e488579077762627dba2cee54ffca64dad17/src/gdbserver/gdb-server.c#L1121

यह फ़ंक्शन कॉल जबकि (1) लूप को समाप्त करने के लिए उचित मान नहीं लौटाता है। समस्याएँ फ़ंक्शन या जबकि (1) तंत्र के अंदर हो सकती हैं।

lldb साथ त्रुटि प्रबंधन प्रक्रिया की जाँच करने के बाद, मुझे शायद गलती कोड का पता चल गया।

https://github.com/texane/stlink/blob/bf840a1ae82ffc3ef9929f243bb8050d6856f698/src/gdbserver/gdb-server.c#L1448

जब _stlink_usb_step शुरू में एक libusb कॉल की विफलता से ट्रिगर हुई त्रुटि का सामना करता है, तो यह एक गैर-शून्य वापसी मान (इस मामले में -1) देता है। हालांकि इस वापसी मूल्य को gdb-server में recv-handle-send लूप द्वारा नियंत्रित नहीं किया जाता है:

https://github.com/texane/stlink/blob/bf840a1ae82ffc3ef9929f243bb8050d6856f698/src/gdbserver/gdb-server.c#L1119

मैं दो संभावित डील रणनीतियों के साथ आया हूं:

सामान्य भाग: स्विच केस में stlink_step के वापसी मूल्य की जाँच करें।

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

विश्लेषण:

विकल्प 1 स्वीकार्य है क्योंकि हम यह अनुमान नहीं लगा सकते कि संचार त्रुटि के बाद क्या होगा। ड्रा बैक यह है कि कुछ अस्थिर यूएसबी पोर्ट या कुछ समान पर सेंट-उपयोग अधिक बार विफल हो सकता है।
विकल्प 2 अस्थिर उपकरणों को एक और मौका देगा लेकिन पैकेट दोहराव का कारण बन सकता है, जो डिबगिंग को थोड़ा अधिक अप्रत्याशित बनाता है।

विस्तृत विश्लेषण के लिए Thx। मैं यहां विकल्प 1 को पसंद करूंगा। यदि लोगों को विशिष्ट स्थानीय हार्डवेयर अस्थिरताओं से संबंधित समस्याओं का सामना करना पड़ता है, तो हम इसके लिए वैसे भी कुछ नहीं कर सकते हैं और यह भी कुछ भी नहीं है जिसे स्टलिंक टूल को ध्यान में रखना चाहिए। यह अधिक महत्वपूर्ण लगता है कि हम डिबगिंग पर कोई समझौता करें। क्या आप इसे तुरंत ठीक कर सकते हैं?

मैं पैकेट (ओं) को ठीक से भेजने के लिए जीडीबी के दस्तावेज़ीकरण की जांच करूंगा। मुझे लगता है कि बहुत मुश्किल नहीं है।
मेरे हो जाने के बाद, मैं एक पीआर बढ़ाऊंगा।

मैंने यह नहीं कहा, लेकिन मैं विकल्प 2 के लिए जा रहा था। लेकिन आपके स्पष्टीकरण के बाद: आप सही कह रहे हैं। आपने मुझे आश्वस्त कर दिया है: जब तक यह मानने का कोई वैध कारण नहीं है कि त्रुटि अस्थायी है, तो त्रुटि को तुरंत घातक माना जाना चाहिए।

उपयोगकर्ता को सूचित किए बिना पुन: प्रयास करने से अचानक आश्चर्य होगा। मान लीजिए कि स्थानांतरित बिट्स का 1/100वां या 1/1000वां भ्रष्ट हो जाता है (किसी भी स्तर पर)। यदि इसका परिणाम 99% समय में एक कमांड "अमान्य" होता है, तो उस स्थिति में उपयोगकर्ता को औसतन बहुत सारी चेतावनियाँ मिलेंगी (अर्थात अचानक छोड़ना) कि उसका हार्डवेयर अस्थिर है इससे पहले कि वह मूक डेटा भ्रष्टाचार प्राप्त करता है जो समस्याओं का कारण बनता है। ...

"आसान तरीका" बस "बाहर निकलें ()" है। वह अचानक जीडीबी से कनेक्शन बंद कर देगा और यह पर्याप्त रूप से इनायत से संभाल लेगा।

बुनियादी कार्य पीआर के तहत एक stm32f401 बोर्ड के साथ अच्छी तरह से चलते हैं।
मेरे स्थानीय परीक्षण के दौरान मृत लूप का समाधान किया गया है। अब st-util बाहर निकल जाएगा। gdb एक विफलता उत्तर प्राप्त करेगा और डिस्कनेक्ट करेगा।