फायरफक्सलाई zlib-rs मा स्थानान्तरण गर्दा, विकासकर्ताहरूले Intel CPU हरूमा बगको सामना गरे।

ntpd-rs, sudo-rs, zlib-rs, र bzip2-rs जस्ता परियोजनाहरूको विकासकर्ता, Trifecta Tech Foundation ले gzip कम्प्रेसन र डिकम्प्रेसनको लागि zlib-rs लाइब्रेरी प्रयोग गर्न फायरफक्सको संक्रमणको घोषणा गर्‍यो। मेमोरी त्रुटिहरूबाट सुरक्षाको अतिरिक्त, zlib बाट zlib-rs मा स्विच गर्नाले कार्यसम्पादनमा उल्लेखनीय वृद्धि भयो - परीक्षणहरूमा, एकल डिकोडिङ अपरेशनहरूको लागि गति ३.३ देखि ३२.५ गुणा र निरन्तर स्ट्रिम डिकोडिङको लागि २.७ देखि १०.८६ गुणा सम्म थियो।

zlib-rs लाइब्रेरीलाई Firefox रिलिज १५१ मा समावेश गरिएको थियो, तर यसको एकीकरण पछि, केही प्रयोगकर्ताहरूले एउटा समस्याको सामना गरे जसको परिणामस्वरूप सीमा बाहिरको कार्यान्वयनको कारणले क्र्यास भयो। यो उल्लेख गरिएको थियो कि Rust कोडमा, यो समस्याले क्र्यास निम्त्यायो, जबकि C कोडमा, यस्तै अवस्थाले कार्यक्रम बन्द नगरी मौन डेटा भ्रष्टाचार निम्त्याउने थियो। समाधानको रूपमा, पुरानो zlib लाइब्रेरीलाई रिलिज १५१.०.१ मा प्रयोग गर्न फिर्ता गरिएको थियो।

समस्याको पहिलो अभिव्यक्ति एक वर्ष भन्दा पहिले प्रारम्भिक निर्माणहरूको परीक्षणको क्रममा देखियो, तर यसलाई विकासकर्ता प्रणालीहरूमा पुन: उत्पादन गर्न सकिएन। अन्ततः, बिटा प्रयोगकर्ताहरूसँग एक वर्षको परीक्षण पछि, फायरफक्स १५१ मा zlib-rs सक्षम गर्ने निर्णय गरियो। समस्या रिपोर्टहरूको नयाँ श्रृंखला र ढाँचाको अनुसन्धान पछि, यो पत्ता लाग्यो कि दुर्घटना १३ औं र १४ औं पुस्ताको र्याप्टर लेक माइक्रोआर्किटेक्चरमा आधारित इन्टेल CPU हरूमा माइक्रोकोड त्रुटिको कारणले भएको थियो, जुन गलत दर्ताको प्रयोगसँग सम्बन्धित थियो।

समस्या आयो किनभने LLVM कोड जेनरेटरले Huffman एन्कोडिङ परिणामहरू मेमोरीमा लेख्दा "mov byte ptr [rsi + rdi + 1], ch" निर्देशन प्रयोग गर्‍यो। Raptor Lake CPU मा यो निर्देशन कार्यान्वयन गर्दा, RCX दर्ताबाट 8-15 बिटहरू लेख्नुको सट्टा, निर्देशनमा निर्दिष्ट CH दर्तासँग मेल खाने, CL दर्तासँग मेल खाने बिटहरू 0-7, मेमोरीमा लेखिएका थिए। Firefox 152 को तयारीमा एक वर्कअराउन्ड लागू गरिएको थियो, र प्याचलाई मुख्य zlib-rs रिलीजमा पोर्ट गरिएको थियो। समस्याग्रस्त निर्देशनको उत्पादन LLVM 22 मा अवलोकन गरिएको थियो (यो LLVM 23 विकास शाखामा उत्पन्न गरिएको छैन)।

स्रोत: opennet.ru