Summary: | media-gfx/eog-2.22.3-r1 fails to show the attached jpeg image | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | José Romildo Malaquias <jrmalaq> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | friemann |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
a.jpg
eog.out.txt |
Description
José Romildo Malaquias
2008-09-16 13:09:19 UTC
Created attachment 165556 [details]
a.jpg
The image intended to be visualized by eog.
Created attachment 165557 [details]
eog.out.txt
The output of running "eog a.jpg"
It appears to be somehow related to the exif headers in the file (which appears to be gzipped...): _int_malloc (av=0x7f758b98ca00, bytes=72) at malloc.c:4442 4442 unlink(victim, bck, fwd); (gdb) bt #0 _int_malloc (av=0x7f758b98ca00, bytes=72) at malloc.c:4442 #1 0x00007f758b6b5128 in *__GI___libc_malloc (bytes=72) at malloc.c:3551 #2 0x00007f758b66b7c8 in _nl_make_l10nflist (l10nfile_list=0x7f758b98c218, dirlist=0x7f758b75d4c0 "/usr/share/locale", dirlist_len=18, mask=6, language=0x409729b0 "en", territory=0x409729b3 "US", codeset=0x409729b6 "utf8", normalized_codeset=0x13c6780 "", modifier=0x0, filename=0x409729d0 "LC_MESSAGES/libexif-12.mo", do_allocate=1) at l10nflist.c:268 #3 0x00007f758b669aca in _nl_find_domain (dirname=0x7f758b75d4c0 "/usr/share/locale", locale=0x409729b0 "en", domainname=0x409729d0 "LC_MESSAGES/libexif-12.mo", domainbinding=0x0) at finddomain.c:138 #4 0x00007f758b66923c in __dcigettext (domainname=0x7f758c588a19 "libexif-12", msgid1=0x7f758c589017 "EXIF marker not found.", msgid2=0x0, plural=0, n=0, category=5) at dcigettext.c:639 #5 0x00007f758c57dba1 in exif_data_load_data (data=0x13c6540, d_orig=0x13ce210 "http://ns.adobe.com/xap/1.0/ ", ds_orig=10070) at exif-data.c:816 #6 0x00007f758c57e2d8 in exif_data_new_from_data (data=0x13ce210 "http://ns.adobe.com/xap/1.0/ ", size=10070) at exif-data.c:151 #7 0x0000000000433e67 in eog_image_load (img=0x13be040, data2read=<value optimized out>, job=0x13f38c0, error=0x13f38d8) at eog-image.c:754 #8 0x000000000043d438 in eog_job_load_run (job=0x13f38c0) at eog-jobs.c:291 #9 0x000000000043ce95 in eog_render_thread (data=<value optimized out>) at eog-job-queue.c:78 #10 0x00007f758bc0e81e in g_thread_create_proxy (data=0x11311c0) at gthread.c:635 #11 0x00007f758cbc2017 in start_thread (arg=<value optimized out>) at pthread_create.c:297 #12 0x00007f758b70bfdd in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? () (gdb) up #1 0x00007f758b6b5128 in *__GI___libc_malloc (bytes=72) at malloc.c:3551 3551 victim = _int_malloc(ar_ptr, bytes); (gdb) up #2 0x00007f758b66b7c8 in _nl_make_l10nflist (l10nfile_list=0x7f758b98c218, dirlist=0x7f758b75d4c0 "/usr/share/locale", dirlist_len=18, mask=6, language=0x409729b0 "en", territory=0x409729b3 "US", codeset=0x409729b6 "utf8", normalized_codeset=0x13c6780 "", modifier=0x0, filename=0x409729d0 "LC_MESSAGES/libexif-12.mo", do_allocate=1) at l10nflist.c:268 268 retval = (struct loaded_l10nfile *) The image has been obtained with the "convert" application from imagemagick, with the command $ convert -crop 200x original.jpg a.jpg Maybe that is relevant. looks like the file is broken here is eog 2.24 output: (Not a JPEG file: starts with 0x1f 0x8b) and here is file output: a.jpg: gzip compressed data, from Unix so there is something really fishy with this file. and for some reason, renaming it to a.jpg.gz makes it a valid archive file, you can extra a.jpg and it shows up properly. Somehow I feel this is not in our basket. Just fixed in EOG's SVN: http://svn.gnome.org/viewvc/eog?view=revision&revision=4811 The problem was that the XMP chunk was not recognized as such and was subsequently skipped. Unfortunately the codepath doing the skipping had a bug which overwrote the already read Exif data with the skipped (larger) XMP data. The oneliner above should fix that. Still the XMP data is not recognized because the identifier is not correct. this is fixed in 2.22.3-r2. |