Mve: makescene falla al importar archivos PNG

Creado en 5 sept. 2017  ·  30Comentarios  ·  Fuente: simonfuhrmann/mve

Tengo un problema con el comandomakescene que no puedo resolver por mí mismo.

He clonado y compilado el repositorio de acuerdo con las instrucciones del Léame.md en Ubuntu 16.04 de 64 bits. La compilación se compila sin errores y todas las aplicaciones están ahí.

Sin embargo, si ejecuto el comandomakescene con los parámetros -i, solo creará la carpeta de escena y luego fallará con el mensaje "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" (ejecuto la versión alemana de Ubuntu)

He agregado mensajes de salida al código para ver qué tan lejos se ejecuta el comando y, aparentemente, el bloqueo ocurre en el archivo image_io.cc, en la función load_png_file, alrededor de las líneas 311-314, donde se configuran los punteros.

Aunque no sé cómo solucionarlo. Los valores de headers.height y headers.channels parecen tener sentido.

Todos 30 comentarios

Un accidente en image_io es relativamente poco probable. ¿Puedes intentar escribir un programa de prueba y cargar la imagen manualmente?

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

¿Hay algo más especial en la imagen? ¿Es un PNG de 8 o 16 bits?

Bien, he compilado el programa de prueba y trato de cargar un PNG que está en la misma carpeta que la aplicación de prueba. Obtengo el mismo resultado, el programa falla con "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)".

Sin embargo, si cambio la llamada de función a "load_tiff_file" y cargo un archivo TIFF en su lugar, parece funcionar bien. ¿Quizás la función load_png_file está rota específicamente?

No estoy seguro de si esto es de alguna ayuda, pero he vuelto a cambiar el código a load_png_file y he usado strace para obtener los registros del sistema relacionados con esta aplicación. Estas son las últimas líneas de ese registro antes de que falle:

14:00:46.197536 abierto("./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 lectura(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 mmap(NULO, 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 +++ eliminado por SIGILL (núcleo volcado) +++

¿Te importaría enviarme un enlace a esa imagen?

Supongo que la imagen solo tiene una extensión png pero en realidad no es un png... He visto problemas similares en los que un archivo ".png" en realidad estaba codificado en jpeg.

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

Usé ffmpeg para exportar los cuadros de un video a archivos de imagen.

Pensé que también podría ser el formato de archivo incorrecto, pero usé el comando de conversión para convertirlo de png a tiff y viceversa, sin ningún efecto.

El archivo carga bien aquí.

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
...

De acuerdo con su strace , su programa es eliminado por SIGILL (no KILL). Creo que esto significa que su procesador o sistema operativo está intentando ejecutar una instrucción no válida. No sé qué hacer con esto, pero creo que es su sistema, o su biblioteca libpng, lo que de alguna manera está en mal estado. ¿Puedes intentar reinstalar/actualizar libpng?

Entonces, desinstalé la versión de libpng que instalé a través de apt-get install y, en su lugar, descargué el repositorio de libpng directamente, lo compilé y lo instalé.

Desafortunadamente, tiene el mismo efecto. ¿Quizás realmente es mi procesador? Actualmente uso un procesador AMD Phenom II X4 965, que no es el modelo más nuevo, supongo. Aún así, no creo que haya tenido problemas similares antes.

De todos modos, dado que ustedes no pueden reproducir el problema, supongo que cerraré el problema.

Lamento escuchar que todavía no funciona. Realmente no creo que sea tu hardware... pero no tengo ideas. ¿Tal vez hay indicadores de tiempo de compilación para deshabilitar ciertas funciones de aceleración para libpng? En este punto, solo estoy adivinando sin saber realmente qué está causando el problema.

Sé por qué Makescene falla al importar archivos de imagen después de muchos experimentos. No es el motivo de libjpeg o libpng, el motivo real es openMP. Puede corregir este error con estos códigos enmakescene.cc:
Línea 845
mve::ImageBase::Ptr imagen;

pragma omp paralelo para programación ordenada (dinámica, 1)

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

....
std::stringexif;

pragma omp crítico

    image = load_any_image(afname, &exif);

...

Pero ese cambio no tiene mucho sentido. Está almacenando la imagen en la variable image que se comparte en todos los subprocesos y, aunque la carga de la imagen está serializada ahora, sobrescribirá la imagen debido a las condiciones de carrera y usará los datos incorrectos después de cargar la imagen. ..

¿Ha intentado simplemente poner el crítico #pragma omp antes de cargar la imagen?

@timlgy , ¿puede contarnos un poco más sobre su sistema? ¿Qué CPU, sistema operativo y compilador estás usando?

Me funciona en Ubuntu 14.04.5 LTS, 16U32G y el compilador es gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) PS 'datos incorrectos' ¿qué es eso? prepaquete.sfm?

segun este articulo #pragma omp critico
La directiva crítica omp identifica una sección de código que debe ser ejecutada por un solo subproceso a la vez.
Así que pensé que tal vez 'load_any_image' es peligroso al poner este código dentro mve::ImageBase::Ptr imagel=oad_any_image(afname, &exif);

load_any_image solo usa libpng en segundo plano, que es seguro para subprocesos cuando se usa correctamente, lo cual espero que hagamos. Por "datos incorrectos", quiero decir que, en el código anterior, la imagen podría sobrescribirse con otra imagen antes de usarla y, por lo tanto, terminaría con los datos de imagen incorrectos en su vista.

Ahora, solo para tener una idea de este problema, ¿quién se ve realmente afectado por estos accidentes?

Cuando cargo solo una imagen (cualquier tipo, jpg, tif o png), está bien, pero cuando cargo dos imágenes (cualquier tipo), se bloquea con una alta probabilidad.

No sé qué causa el problema. La carga de imágenes debería ser posible en paralelo, y nunca he visto problemas. ¿Este bloqueo puede estar relacionado con su memoria disponible, si carga imágenes realmente grandes? Puedo imaginar que cargar 32 imágenes (en caso de que tenga tantos núcleos) en paralelo en una máquina de 2 GB de RAM causará problemas.

Mientras tanto, simplemente coloque una línea #pragma omp critical antes load_any_image , lo que debería resolver el problema.

@timlgy , ¿puedes publicar un seguimiento del accidente?
Además, ¿qué quieres decir con "16U32G"?

@andre-schulz 16U32G significa CPU 16 subprocesos múltiples y memoria de 32 GB

Observo el mismo bloqueo en Windows 7 64x con la última instrucción de compilación mve:

crash

Intenté "poner una línea #pragma omp crítica antes de cargar_cualquier_imagen", pero esto no ayuda, en este caso no puedo compilar. ¿Cómo podemos resolver esto? ¿Cuál es el propósito de usar OpenMP aquí?

image

Intenté importar solo una imagen: también obtengo el mismo bloqueo.

Hola @stiv-yakovenko,
gracias por la información. ¿Es posible que publiques el archivo png que está causando el problema?
Además, ¿qué CPU estás usando?

cpuz

El problema parece ser que makescene se compiló en modo de depuración pero se vinculó a libpng en modo de lanzamiento; probablemente un problema con la vinculación con diferentes bibliotecas de tiempo de ejecución (/MD vs. /MDd). Este es un problema con la forma en que funciona el sistema de compilación actual. Tengo que investigar esto más a fondo.
¿Puedes confirmar que makescene funciona en el modo RelWithDebInfo?

Si necesita ejecutar makescene en modo de depuración, puede compilar las bibliotecas de terceros en modo de depuración agregando Debug a CMAKE_CONFIGURATION_TYPES en el tercero CMakeLists.txt . Luego, vuelva a compilar y copie las versiones de depuración de las bibliotecas a mano en la ubicación de la versión de depuración de makescene . Intentaré averiguar si puedo arreglar/automatizar esto de alguna manera.

Confirmo que la versión ReleaseWithDeb funciona.

@andre-schulz Hola, gracias por tu análisis sobre el modo de depuración. Volví a compilar las bibliotecas de terceros en modo de depuración y agregué tiffd.dll, zlibd.dll a la versión de depuración demakescene. El programa aún fallaba

png_read_image(png, &row_pointers[0]);

image

@andre-schulz ¡Está bien ahora! Después de una compilación completa de la depuración después de modificar CMAKE_CONFIGURATION_TYPES en CMakeLists.txt de las bibliotecas de terceros y modificar la configuración de lib de entrada de MVE.sln, se resolvió el problema de carga de jpg.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

HelliceSaouli picture HelliceSaouli  ·  14Comentarios

HelliceSaouli picture HelliceSaouli  ·  12Comentarios

daleydeng picture daleydeng  ·  8Comentarios

Jus80687 picture Jus80687  ·  11Comentarios

GustavoCamargoRL picture GustavoCamargoRL  ·  13Comentarios