Bug 614745

Created attachment 431983 [details]
File: backtrace

Looks like a libtiff bug (?). Re-assigning.

Could we see the file involved?  Looks like it was 
file:///mnt/gigacomdat/Gigames/Oficina%20Tecnica%20I+D/Documentacion%20I+D/DISE%C3%91O/DISE%C3%91O%20GR%C3%81FICO/ZP0947/4090200610%200947M003A3%20CF/PARA%20FILMAR/FILMAR/TIFFS/Gemma_AZUL.tif

Also, what version of libtiff do you have installed?

Hello Tom,

The version of libtiff is libtiff-3.9.4.1.fc13.i686

I submit the file.

Created attachment 432106 [details]
file Gemma_AZUL.tif

The mount point on it was allocated this file is very veryyyyyyyyy slow

Well, I don't see anything wrong with the TIFF file, and libtiff doesn't crash on it when invoked using ordinary command line tools.  So what I guess at the moment is that tracker is using libtiff incorrectly somehow.  I do not know anything about tracker, and in particular not how to get it to process a specific file in order to reproduce the problem --- any suggestions?

Backtrace file :

#Core was generated by `/usr/libexec/tracker-extract'.
#Program terminated with signal 7, Bus error.


This type of error occurs when you are reading a file and the reading is interrupted by a problem on the bus (USB bus, bus ethernet, ....)

The directory /mnt/gigacomdat is exported via CIFS from a windows server in a remote location. And sometimes the Windows server does not work very well or is extremely slow.

> This type of error occurs when you are reading a file and the reading is
> interrupted by a problem on the bus (USB bus, bus ethernet, ....)

Uh, no, that has nothing to do with it.  In this context it probably indicates an attempt to use a bad memory address, eg unaligned address.  The stack trace is additional evidence that there's no direct connection to the reading of the file.

I'm still wondering what I have to do to reproduce the problem.  Deji?

(In reply to comment #8)
> > This type of error occurs when you are reading a file and the reading is
> > interrupted by a problem on the bus (USB bus, bus ethernet, ....)
> 
> Uh, no, that has nothing to do with it.  In this context it probably indicates
> an attempt to use a bad memory address, eg unaligned address.  The stack trace
> is additional evidence that there's no direct connection to the reading of the
> file.
> 
> I'm still wondering what I have to do to reproduce the problem.  Deji?    

I'm trying to get tracker devs to look at it, it could very well be tracker-extract's problem; will get back to you.

Neither I nor upstream can reproduce the crash. I've tested with tracker-0.8.13-1.fc13.x86_64 and libtiff-3.9.4-1.fc13.x86_64.

>>
[deji@logos ~]$ /usr/libexec/tracker-extract -f Downloads/Gemma_AZUL.tif
...
<--- [1] tracker_extract_get_metadata_by_cmdline(uri:'file:///home/deji/Downloads/Gemma_AZUL.tif', mime:(null))
---- [1]   Guessing mime type as 'image/tiff' for uri:'file:///home/deji/Downloads/Gemma_AZUL.tif'
---- [1]   Extracting with module:'/usr/lib64/tracker-0.8/extract-modules/libextract-tiff.so'
TIFFReadDirectory: Warning, /home/deji/Downloads/Gemma_AZUL.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored.
---- [1]   Found 7 metadata items
---- [1] 
---- [1]  a nfo:Image , nmm:Photo ;
	 nfo:width "236" ;
	 nfo:height "177" ;
	 dc:format "image/tiff" ;
	 nfo:orientation "nfo:orientation-top-mirror" ;
	 nie:contentCreated "2009-12-21T17:45:24" .

---> [1] Success, no error given
>>

[ digs some more ... ]

Actually, maybe Alfredo's idea that the slow/unreliable server has something to do with it is right.  The stack trace proves that libtiff successfully read the tiff file's main directory (since it found the EXIFIFDOffset tag and got the right value out of it) and then crashed while trying to access the EXIF subdirectory, which is near the end of the file (in this case; in general it could be anywhere).  And libtiff was using memory-mapped access to the file, which means that the kernel has no way to report a read failure other than crashing the process.  I wonder whether the attempt to fetch the end area of the file failed and the kernel chose to deliver SIGBUS instead of allowing the process to read certainly-incorrect data from the mapped area.

If that's the explanation, there may be little we can do about it.  You could make tracker tell libtiff not to use memory mapping, but I'm dubious that you want to optimize tracker for unreliable servers, or that this would be the only failure mode anyway.

Also, if comment #11 is the correct explanation, then Alfredo himself should be unable to reproduce the crash with any reliability.  Alfredo, if you try "/usr/libexec/tracker-extract -f .../Gemma_AZUL.tif", how often does it fail?  If you can get it to fail, try copying the file to local storage and seeing what happens when reading from there.

Now I have made 20 attempts and all have worked well. I have no way to reproduce the error again:

[apons@atlantis ~]$ /usr/libexec/tracker-extract -f /mnt/gigacomdat/Gigames/Oficina\ Tecnica\ I+D/Documentacion\ I+D/DISEÑO/DISEÑO\ GRÁFICO/ZP0947/4090200610\ 0947M003A3\ CF/PARA\ FILMAR/FILMAR/TIFFS/Gemma_AZUL.tif
Initializing tracker-extract...
Initializing Storage...
Mount monitors set up for to watch for added, removed and pre-unmounts...
No mounts found to iterate
Setting process priority
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-ps.so' with:
  Specific match for mime:'application/x-gzpostscript'
  Specific match for mime:'application/postscript'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-pdf.so' with:
  Specific match for mime:'application/pdf'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-xmp.so' with:
  Specific match for mime:'application/rdf+xml'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-html.so' with:
  Specific match for mime:'text/html'
  Specific match for mime:'application/xhtml+xml'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-abw.so' with:
  Specific match for mime:'application/x-abiword'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-oasis.so' with:
  Generic  match for mime:'application/vnd.oasis.opendocument.*'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-tiff.so' with:
  Specific match for mime:'image/tiff'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-msoffice.so' with:
  Specific match for mime:'application/msword'
  Specific match for mime:'application/vnd.ms-powerpoint'
  Specific match for mime:'application/vnd.ms-excel'
  Generic  match for mime:'application/vnd.ms-*'
  Specific match for mime:'application/vnd.openxmlformats-officedocument.presentationml.presentation'
  Specific match for mime:'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
  Specific match for mime:'application/vnd.openxmlformats-officedocument.wordprocessingml.document'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-gstreamer.so' with:
  Generic  match for mime:'audio/*'
  Generic  match for mime:'video/*'
  Generic  match for mime:'image/*'
  Specific match for mime:'video/3gpp'
  Specific match for mime:'video/mp4'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-png.so' with:
  Specific match for mime:'image/png'
  Specific match for mime:'sketch/png'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-text.so' with:
  Generic  match for mime:'text/*'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-jpeg.so' with:
  Specific match for mime:'image/jpeg'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-mp3.so' with:
  Specific match for mime:'audio/mpeg'
  Specific match for mime:'audio/x-mp3'
Adding extractor:'/usr/lib/tracker-0.8/extract-modules/libextract-playlist.so' with:
  Specific match for mime:'audio/x-mpegurl'
  Specific match for mime:'audio/mpegurl'
  Specific match for mime:'audio/x-scpls'
  Specific match for mime:'audio/x-pn-realaudio'
  Specific match for mime:'application/ram'
  Specific match for mime:'application/vnd.ms-wpl'
  Specific match for mime:'application/smil'
  Specific match for mime:'audio/x-ms-asx'
<--- [1] tracker_extract_get_metadata_by_cmdline(uri:'file:///mnt/gigacomdat/Gigames/Oficina%20Tecnica%20I+D/Documentacion%20I+D/DISE%C3%91O/DISE%C3%91O%20GR%C3%81FICO/ZP0947/4090200610%200947M003A3%20CF/PARA%20FILMAR/FILMAR/TIFFS/Gemma_AZUL.tif', mime:(null))
---- [1]   Guessing mime type as 'image/tiff' for uri:'file:///mnt/gigacomdat/Gigames/Oficina%20Tecnica%20I+D/Documentacion%20I+D/DISE%C3%91O/DISE%C3%91O%20GR%C3%81FICO/ZP0947/4090200610%200947M003A3%20CF/PARA%20FILMAR/FILMAR/TIFFS/Gemma_AZUL.tif'
---- [1]   Extracting with module:'/usr/lib/tracker-0.8/extract-modules/libextract-tiff.so'
---- [1]   Found 7 metadata items
---- [1] 
---- [1]  a nfo:Image , nmm:Photo ;
	 nfo:width "236" ;
	 nfo:height "177" ;
	 dc:format "image/tiff" ;
	 nfo:orientation "nfo:orientation-top-mirror" ;
	 nie:contentCreated "2009-12-21T17:45:24" .

---> [1] Success, no error given



All ok.
If it happens again this bug on my PC, I'll try to make this from the terminal again.

*** Bug 618513 has been marked as a duplicate of this bug. ***

Closing as WONTFIX per comment #11: there is nothing to be done about this in libtiff, and it seems unlikely that tracker should be made slower in order to handle the case more gracefully.