Mve: يتسبب في حدوث تعطل عند استيراد ملفات PNG

تم إنشاؤها على ٥ سبتمبر ٢٠١٧  ·  30تعليقات  ·  مصدر: simonfuhrmann/mve

لدي مشكلة في أمر makecene ولا يمكنني حلها بنفسي.

لقد قمت باستنساخ وإنشاء المستودع وفقًا للإرشادات الواردة في الملف التمهيدي. يجمع الإصدار بدون أخطاء وجميع التطبيقات موجودة.

ومع ذلك ، إذا قمت بتشغيل الأمر makecene مع المعلمات -i، سيتم فقط إنشاء مجلد المشهد ثم تعطل الرسالة "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" (قمت بتشغيل الإصدار الألماني من Ubuntu)

لقد أضفت رسائل الإخراج إلى الكود لمعرفة المدى الذي يتم فيه تنفيذ الأمر ، ويبدو أن التعطل يحدث في ملف image_io.cc ، في وظيفة load_png_file ، حول الأسطر 311-314 ، حيث تم إعداد المؤشرات.

لا أعرف كيف أصلحه ، رغم ذلك. يبدو أن قيم قنوات الارتفاع والعناوين تبدو منطقية.

ال 30 كومينتر

من غير المحتمل نسبيًا حدوث عطل في image_io . هل يمكنك محاولة كتابة برنامج اختبار وتحميل الصورة يدويًا؟

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

هل هناك شيء آخر مميز في الصورة؟ هل هي PNG ذات 8 أم 16 بت؟

حسنًا ، لقد قمت بتجميع برنامج الاختبار وحاول تحميل ملف PNG موجود في نفس المجلد مثل تطبيق الاختبار. حصلت على نفس النتيجة ، تعطل البرنامج مع "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)".

ومع ذلك ، إذا قمت بتغيير استدعاء الوظيفة إلى "load_tiff_file" وقمت بتحميل ملف TIFF بدلاً من ذلك ، يبدو أنه يعمل بشكل جيد. ربما تم تعطيل وظيفة load_png_file على وجه التحديد؟

لست متأكدًا مما إذا كان هذا مفيدًا ، لكنني قمت بتغيير الرمز مرة أخرى إلى load_png_file واستخدمت strace للحصول على سجلات النظام المتعلقة بهذا التطبيق. هذه هي الأسطر القليلة الأخيرة من ذلك السجل قبل أن يتعطل:

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 \ 0 \ 2 \ 320 \ 10 \ 2 \ 0 \ 0 \ 0 @ \ 37J "...، 4096) = 4096
14: 00: 46.197651 ملمب (NULL، 2768896، PROT_READ | PROT_WRITE، MAP_PRIVATE | MAP_ANONYMOUS، -1، 0) = 0x7fcadc163000
14: 00: 46.198666 --- SIGILL {si_signo = SIGILL، si_code = ILL_ILLOPN، si_addr = 0x40b69d} ---
14: 00: 46.337334 +++ قتل من قبل SIGILL (تم تفريغ النواة) +++

هل تمانع في أن ترسل لي رابطًا لتلك الصورة؟

تخميني هو أن الصورة تحتوي فقط على امتداد png ولكنها في الواقع ليست png ... لقد رأيت مشكلات مماثلة حيث تم بالفعل ترميز ملف ".png" بتنسيق jpeg.

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

لقد استخدمت ffmpeg لتصدير إطارات الفيديو إلى ملفات الصور.

اعتقدت أنه قد يكون تنسيق الملف خاطئًا أيضًا ، لكنني استخدمت الأمر convert لتحويله من png إلى tiff والعكس ، دون أي تأثير.

يتم تحميل الملف بشكل جيد هنا.

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 (وليس القتل). أعتقد أن هذا يعني أن المعالج أو نظام التشغيل لديك يحاول تنفيذ تعليمات غير صالحة. لا أعرف ماذا أفعل بهذا ، لكنني أعتقد أنه نظامك ، أو مكتبة libpng الخاصة بك معطلة بطريقة ما. هل يمكنك محاولة إعادة تثبيت / ترقية libpng؟

لذلك ، قمت بإلغاء تثبيت إصدار libpng الذي قمت بتثبيته عبر apt-get install وبدلاً من ذلك قمت بتنزيل مستودع libpng مباشرةً ، وقمت بتجميعه.

لسوء الحظ ، لها نفس التأثير. ربما هو حقا المعالج الخاص بي؟ أستخدم حاليًا معالج AMD Phenom II X4 965 ، وهو ليس أحدث طراز ، على ما أعتقد. ومع ذلك ، لا أعتقد أنني واجهت أي مشاكل مماثلة من قبل.

على أي حال ، نظرًا لأنكم لا تستطيعون إعادة إنتاج المشكلة ، أعتقد أنني سأغلق المشكلة.

أنا آسف لسماع أنه لا يزال لا يعمل. لا أعتقد حقًا أنه أجهزتك ... لكنني نفدت الأفكار. ربما هناك إشارات وقت الترجمة لتعطيل ميزات تسريع معينة لـ libpng؟ في هذه المرحلة ، أخمن فقط دون معرفة سبب المشكلة.

أعرف سبب تعطل المشهد عند استيراد ملفات الصور بعد العديد من التجارب. إنه ليس سبب libjpeg أو libpng ، السبب الحقيقي هو openMP. يمكنك إصلاح هذا الخطأ باستخدام هذه الرموز في makecene.cc:
845 خط
mve :: ImageBase :: Ptr image ؛

pragma omp المتوازي للجدول المرتب (ديناميكي ، 1)

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

....
الأمراض المنقولة جنسيا :: سلسلة exif ؛

pragma omp حرجة

    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 "بيانات خاطئة" ما هذا؟ prebundle.sfm؟

وفقا لهذا المقال # pragma omp حرجة
يحدد التوجيه الحرج omp قسمًا من الكود يجب تنفيذه بواسطة مؤشر ترابط واحد في كل مرة.
لذلك اعتقدت أن "load_any_image" قد يكون خطيرًا عند وضع هذا الرمز داخل mve::ImageBase::Ptr imagel=oad_any_image(afname, &exif);

يستخدم $ load_any_image فقط libpng في الخلفية وهو آمن للخيط عند استخدامه بشكل صحيح ، وهو ما أتمنى أن نفعله. أعني بعبارة "بيانات خاطئة" ، في الكود أعلاه ، أنه يمكن الكتابة فوق الصورة بصورة أخرى قبل استخدامها ، وبالتالي ينتهي بك الأمر ببيانات صورة خاطئة في وجهة نظرك.

الآن فقط للتعرف على هذه المشكلة ، من الذي تأثر بالفعل بهذه الحوادث؟

عندما أقوم بتحميل صورة واحدة فقط (أي نوع jpg tif أو png) لا بأس بذلك ، ولكن عندما أقوم بتحميل صورتين (من أي نوع) فإنه يتعطل مع احتمال كبير.

لا أعرف ما الذي يسبب المشكلة. يجب أن يكون تحميل الصور ممكنًا بشكل متوازٍ ، ولم أشاهد مشاكل من قبل. هل قد يكون هذا الانهيار متعلقًا بالذاكرة المتوفرة لديك ، إذا قمت بتحميل صور كبيرة حقًا؟ يمكنني أن أتخيل أن تحميل 32 صورة (في حال كان لديك العديد من النوى) بالتوازي على جهاز ذاكرة وصول عشوائي بسعة 2 جيجابايت سيؤدي إلى حدوث مشكلات.

في غضون ذلك ، ضع سطرًا #pragma omp critical قبل load_any_image ، والذي من شأنه حل المشكلة.

timlgy ، هل يمكنك نشر تعقب خلفي للحادث؟
أيضا ، ماذا تقصد بـ "16U32G"؟

@ andre-schulz 16U32G تعني وحدة المعالجة المركزية 16 خيوط متعددة وذاكرة 32 جيجا بايت

لقد لاحظت نفس الانهيار على Windows 7 64x مع أحدث إنشاء mve حسب التعليمات:

crash

حاولت "وضع سطر #pragma omp حرجًا قبل load_any_image" ، لكن هذا لا يساعد ، في هذه الحالة لا يمكنني الإنشاء. كيف يمكننا حل هذا؟ ما هو الغرض من استخدام OpenMP هنا؟

image

حاولت استيراد صورة واحدة فقط: أعاني أيضًا من نفس الانهيار.

مرحبًا @ stiv-yakovenko ،
اشكرك على المعلومات. هل من الممكن أن تنشر ملف png الذي يسبب المشكلة؟
أيضًا ، ما وحدة المعالجة المركزية التي تستخدمها؟

cpuz

يبدو أن المشكلة هي أن makescene تم تجميعه في وضع التصحيح ولكنه مرتبط بـ libpng في وضع الإصدار ؛ من المحتمل وجود مشكلة في الارتباط بمكتبات وقت تشغيل مختلفة (/ MD مقابل / MDd). هذه مشكلة في طريقة عمل نظام البناء الحالي. لا بد لي من التحقيق في هذا أكثر.
هل يمكنك تأكيد أن makescene يعمل في وضع RelWithDebInfo؟

إذا كنت تريد تشغيل makescene في وضع التصحيح ، فيمكنك تجميع مكتبات الطرف الثالث في وضع التصحيح عن طريق إضافة Debug إلى CMAKE_CONFIGURATION_TYPES في الطرف الثالث CMakeLists.txt . بعد ذلك ، أعد ترجمة إصدارات تصحيح الأخطاء للمكتبات وانسخها يدويًا إلى موقع إصدار Debug الخاص بـ makescene . سأحاول معرفة ما إذا كان بإمكاني إصلاح / أتمتة هذا بطريقة ما.

أؤكد أن إصدار ReleaseWithDeb يعمل.

@ andre-schulz مرحبًا ، شكرًا لتحليلك حول وضع التصحيح. لقد أعدت ترجمة مكتبات الطرف الثالث في وضع التصحيح وإضافة tiffd.dll و zlibd.dll إلى إصدار تصحيح الأخطاء من makecene. لا يزال البرنامج يتعطل

png_read_image(png, &row_pointers[0]);

image

@ andre-schulz كل شيء على ما يرام الآن! بعد التحويل البرمجي الكامل لتصحيح الأخطاء بعد تعديل CMAKE_CONFIGURATION_TYPES في CMakeLists.txt من مكتبات الطرف الثالث وتعديل تكوين lib للإدخال لـ MVE.sln ، تم حل مشكلة تحميل jpg.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

daleydeng picture daleydeng  ·  8تعليقات

HelliceSaouli picture HelliceSaouli  ·  14تعليقات

GustavoCamargoRL picture GustavoCamargoRL  ·  13تعليقات

HelliceSaouli picture HelliceSaouli  ·  12تعليقات

Jus80687 picture Jus80687  ·  11تعليقات