image_io में दुर्घटना की संभावना अपेक्षाकृत कम है। क्या आप एक परीक्षण कार्यक्रम लिखने और छवि को मैन्युअल रूप से लोड करने का प्रयास कर सकते हैं?

#include "mve/image_io.h"
int main() {
  mve::image::load_png_file("your path");
  return 0;
}

क्या छवि के बारे में कुछ और खास है? क्या यह 8 या 16 बिट पीएनजी है?

ठीक है, मैंने परीक्षण कार्यक्रम संकलित किया है और एक पीएनजी लोड करने का प्रयास किया है जो परीक्षण ऐप के समान फ़ोल्डर में है। मुझे एक ही परिणाम मिलता है, कार्यक्रम "अनगुल्टिगर मास्चिनेनबेफेल (स्पीचेरबज़ग गेस्क्रिबेन)" के साथ दुर्घटनाग्रस्त हो जाता है।

हालांकि, अगर मैं फ़ंक्शन कॉल को "load_tiff_file" में बदलता हूं और इसके बजाय एक TIFF फ़ाइल लोड करता हूं, तो ऐसा लगता है कि यह ठीक चल रहा है। शायद load_png_file फ़ंक्शन विशेष रूप से टूटा हुआ है?

सुनिश्चित नहीं है कि यह किसी भी मदद की है, लेकिन मैंने कोड को वापस load_png_file में बदल दिया है और इस ऐप से संबंधित सिस्टम लॉग प्राप्त करने के लिए स्ट्रेस का उपयोग किया है। क्रैश होने से पहले ये उस लॉग की अंतिम कुछ पंक्तियाँ हैं:

14:00: 46.197536 खुला ("./frame_0001.png", O_RDONLY) = 3
14:00:46.197561 fstat(3, {st_mode=S_IFREG|0664, st_size=407653, ...}) = 0
14:00:46.197582 पढ़ें(3, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\5\0\0\2\320\10\2\0 \0\0@\37J"..., 4096) = 4096
14:00:46.197651 mmap(NULL, 2768896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcadc163000
14:00:46.198666 --- सिगिल {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x40b69d} ---
14:00: 46.337334 +++ सिगिल द्वारा मारे गए (कोर डंप किया गया) +++

क्या आप मुझे उस छवि का लिंक भेजने में कोई आपत्ति कर रहे हैं?

मेरा अनुमान है कि छवि में सिर्फ एक पीएनजी एक्सटेंशन है लेकिन वास्तव में एक पीएनजी नहीं है ... मैंने ऐसे ही मुद्दों को देखा है जहां एक ".पीएनजी" फ़ाइल वास्तव में जेपीईजी एन्कोडेड थी।

http://maxdid.it/gamejam/img/frame_0001.png

मैंने एक वीडियो के फ्रेम को छवि फ़ाइलों में निर्यात करने के लिए ffmpeg का उपयोग किया।

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

फ़ाइल यहाँ ठीक लोड होती है।

open("frame_0001.png", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0640, st_size=691915, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5395d8a000
read(3, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\5\0\0\0\2\320\10\2\0\0\0@\37J"..., 4096) = 4096
mmap(NULL, 2768896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5393b87000
read(3, "\7\0?)\363\207i\27\30x'\356\330\214Xg\7\260\334W\23G\371\323\31 \323\2S\273\353\\"..., 4096) = 4096
...

आपके strace के अनुसार, आपका प्रोग्राम SIGILL (KILL नहीं) द्वारा मारा गया है। मेरा मानना ​​है कि इसका मतलब है कि आपका प्रोसेसर या ओएस एक अमान्य निर्देश को निष्पादित करने का प्रयास कर रहा है। मुझे नहीं पता कि इसका क्या बनाना है, लेकिन मेरा मानना ​​​​है कि यह आपका सिस्टम है, या आपकी libpng लाइब्रेरी है जो किसी तरह गड़बड़ है। क्या आप libpng को पुनः स्थापित/अपग्रेड करने का प्रयास कर सकते हैं?

इसलिए, मैंने apt-get install के माध्यम से स्थापित किए गए libpng संस्करण को अनइंस्टॉल कर दिया है और इसके बजाय सीधे libpng रिपॉजिटरी को डाउनलोड किया है, इसे एक इंस्टॉल किया है।

दुर्भाग्य से, इसका एक ही प्रभाव है। शायद यह वास्तव में मेरा प्रोसेसर है? मैं वर्तमान में एक AMD Phenom II X4 965 प्रोसेसर का उपयोग करता हूं, जो कि नवीनतम मॉडल नहीं है, मुझे लगता है। फिर भी, मुझे नहीं लगता कि मुझे पहले कभी भी इसी तरह की कोई समस्या हुई थी।

वैसे भी, चूंकि आप लोग समस्या का पुनरुत्पादन नहीं कर सकते हैं, मुझे लगता है कि मैं इस मुद्दे को बंद कर दूंगा।

मुझे यह सुनकर खेद है कि यह अभी भी काम नहीं करता है। मुझे नहीं लगता कि यह आपका हार्डवेयर है... लेकिन मैं विचारों से बाहर हूं। हो सकता है कि libpng के लिए कुछ त्वरण सुविधाओं को अक्षम करने के लिए संकलन-समय के झंडे हों? इस बिंदु पर मैं वास्तव में यह जाने बिना अनुमान लगा रहा हूं कि समस्या क्या है।

मुझे पता है कि कई प्रयोगों के बाद छवि फ़ाइलों को आयात करते समय मेकसीन क्रैश क्यों होता है। यह libjpeg या libpng का कारण नहीं है, वास्तविक कारण openMP है। आप Makecene.cc में इन कोडों के साथ इस बग को ठीक कर सकते हैं:
845 लाइन
mve::ImageBase::Ptr छवि;

आदेशित अनुसूची के लिए प्रगति omp समानांतर (गतिशील, 1)

for (std::size_t i = 0; i < dir.size(); ++i)

....
एसटीडी :: स्ट्रिंग एक्सिफ;

प्रज्ञा ओएमपी क्रिटिकल

    image = load_any_image(afname, &exif);

...

लेकिन यह बदलाव बहुत मायने नहीं रखता। आप छवि को image चर में संग्रहीत कर रहे हैं जो सभी थ्रेड्स में साझा किया गया है, और हालांकि छवि लोड करना अब क्रमबद्ध है, आप दौड़ की स्थिति के कारण छवि को अधिलेखित कर देंगे और छवि लोड करने के बाद गलत डेटा का उपयोग करेंगे। ..

क्या आपने इमेज लोड होने से पहले सिर्फ #pragma omp क्रिटिकल डालने की कोशिश की है?

@timlgy , क्या आप कृपया हमें अपने सिस्टम के बारे में कुछ और बता सकते हैं? आप किस सीपीयू, ऑपरेटिंग सिस्टम और कंपाइलर का उपयोग कर रहे हैं?

यह मेरे लिए Ubuntu 14.04.5 LTS, 16U32G पर काम करता है और कंपाइलर gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) PS 'गलत डेटा' है, वह क्या है? प्रीबंडल.एसएफएम?

इस लेख के अनुसार #pragma omp क्रिटिकल
omp क्रिटिकल डायरेक्टिव कोड के एक सेक्शन की पहचान करता है जिसे एक समय में एक ही थ्रेड द्वारा निष्पादित किया जाना चाहिए।
इसलिए मैंने सोचा कि शायद इस कोड को mve::ImageBase::Ptr imagel=oad_any_image(afname, &exif); के अंदर डालते समय 'load_any_image' खतरनाक है

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

अब बस इस मुद्दे को समझने के लिए, इन दुर्घटनाओं से वास्तव में कौन प्रभावित होता है?

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

मुझे नहीं पता कि समस्या का कारण क्या है। छवियों को लोड करना समानांतर में संभव होना चाहिए, और मैंने कभी भी मुद्दों को नहीं देखा है। यदि आप वास्तव में बड़ी छवियों को लोड करते हैं, तो क्या यह दुर्घटना आपकी उपलब्ध स्मृति से संबंधित हो सकती है? मैं कल्पना कर सकता हूं कि 2 जीबी रैम मशीन पर समानांतर में 32 छवियों (यदि आपके पास इतने कोर हैं) लोड करने से समस्याएं पैदा होंगी।

इस बीच, $#$ load_any_image $#$ से पहले केवल #pragma omp critical एक लाइन डालें, जिससे समस्या का समाधान हो जाए।

@timlgy , क्या आप दुर्घटना का बैकट्रैक पोस्ट कर सकते हैं?
साथ ही, "16U32G" से आपका क्या अभिप्राय है?

@andre-schulz 16U32G का अर्थ है CPU 16 मल्टीपल थ्रेड्स और 32GB मेम

मैं विंडोज 7 64x पर एक ही दुर्घटना का निरीक्षण करता हूं जिसमें निर्देश द्वारा नवीनतम एमवी निर्माण होता है:

लोड_एनी_इमेज से पहले ''एक लाइन #pragma omp क्रिटिकल डालने'' की कोशिश की, लेकिन यह मदद नहीं करता है, इस मामले में मैं निर्माण नहीं कर सकता। हम इसे कैसे हल कर सकते हैं? यहां ओपनएमपी का उपयोग करने का उद्देश्य क्या है?

सिर्फ एक छवि आयात करने का प्रयास किया: मुझे भी वही दुर्घटना मिलती है।

हाय @ स्टिव-याकोवेंको,
जानकारी के लिए आभार। क्या आपके लिए समस्या पैदा करने वाली पीएनजी फ़ाइल पोस्ट करना संभव है?
इसके अलावा, आप किस सीपीयू का उपयोग कर रहे हैं?

0.ज़िप

समस्या यह प्रतीत होती है कि makescene डीबग मोड में संकलित किया गया था लेकिन रिलीज मोड में libpng से जुड़ा हुआ था; शायद विभिन्न रनटाइम पुस्तकालयों (/ एमडी बनाम/एमडीडी) के खिलाफ जोड़ने में कोई समस्या है। मौजूदा बिल्ड सिस्टम के काम करने के तरीके में यह एक समस्या है। मुझे इसकी और जांच-पड़ताल करनी है।
क्या आप पुष्टि कर सकते हैं कि makescene RelWithDebInfo मोड में काम करता है?

यदि आपको डीबग मोड में makescene चलाने की आवश्यकता है, तो आप तृतीय पक्ष $#$ CMakeLists.txt $#$ में Debug से CMAKE_CONFIGURATION_TYPES जोड़कर डीबग मोड में तृतीय पक्ष पुस्तकालयों को संकलित कर सकते हैं। फिर, पुस्तकालयों के डीबग संस्करणों को makescene के डीबग संस्करण के स्थान पर हाथ से पुन: संकलित और कॉपी करें। मैं यह पता लगाने की कोशिश करूंगा कि क्या मैं इसे किसी तरह ठीक/स्वचालित कर सकता हूं।

मैं पुष्टि करता हूं कि रिलीजविथडेब संस्करण काम करता है।

@ andre-schulz हाय, डिबग मोड के बारे में आपके विश्लेषण के लिए धन्यवाद। मैंने डीबग मोड में तृतीय पक्ष पुस्तकालयों को फिर से संकलित किया है और मेकसीन के डीबग संस्करण में tiffd.dll, zlibd.dll जोड़ें। कार्यक्रम अभी भी दुर्घटनाग्रस्त हो गया

png_read_image(png, &row_pointers[0]);

@ आंद्रे-शुल्ज अब ठीक है! तृतीय पक्ष पुस्तकालयों के CMakeLists.txt में CMAKE_CONFIGURATION_TYPES को संशोधित करने और MVE.sln के इनपुट लिब कॉन्फ़िगरेशन को संशोधित करने के बाद डीबग के पूर्ण संकलन के बाद, यह jpg लोडिंग समस्या के लिए हल हो गया है।