Bug 614745 - [abrt] crash in tracker-0.8.13-1.fc13: __memcpy_ssse3: Process /usr/libexec/tracker-extract was killed by signal 7 (SIGBUS)
[abrt] crash in tracker-0.8.13-1.fc13: __memcpy_ssse3: Process /usr/libexec/t...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libtiff (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
abrt_hash:7c26bed78ea0bb5616c99102937...
:
: 618513 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-15 03:00 EDT by Alfredo Pons Menargues
Modified: 2013-07-02 23:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-15 20:08:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (64.10 KB, text/plain)
2010-07-15 03:01 EDT, Alfredo Pons Menargues
no flags Details
file Gemma_AZUL.tif (194.02 KB, image/tiff)
2010-07-15 11:06 EDT, Alfredo Pons Menargues
no flags Details

  None (edit)
Description Alfredo Pons Menargues 2010-07-15 03:00:55 EDT
abrt 1.1.1 detected a crash.

architecture: i686
Attached file: backtrace
cmdline: /usr/libexec/tracker-extract
component: tracker
crash_function: __memcpy_ssse3
executable: /usr/libexec/tracker-extract
global_uuid: 7c26bed78ea0bb5616c99102937c3b3d749e5feb
kernel: 2.6.33.6-147.fc13.i686
package: tracker-0.8.13-1.fc13
rating: 4
reason: Process /usr/libexec/tracker-extract was killed by signal 7 (SIGBUS)
release: Fedora release 13 (Goddard)
Comment 1 Alfredo Pons Menargues 2010-07-15 03:01:02 EDT
Created attachment 431983 [details]
File: backtrace
Comment 2 Deji Akingunola 2010-07-15 09:38:55 EDT
Looks like a libtiff bug (?). Re-assigning.
Comment 3 Tom Lane 2010-07-15 09:59:00 EDT
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?
Comment 4 Alfredo Pons Menargues 2010-07-15 11:04:58 EDT
Hello Tom,

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

I submit the file.
Comment 5 Alfredo Pons Menargues 2010-07-15 11:06:33 EDT
Created attachment 432106 [details]
file Gemma_AZUL.tif

The mount point on it was allocated this file is very veryyyyyyyyy slow
Comment 6 Tom Lane 2010-07-15 14:08:04 EDT
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?
Comment 7 Alfredo Pons Menargues 2010-07-16 07:45:13 EDT
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.
Comment 8 Tom Lane 2010-07-16 10:08:22 EDT
> 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?
Comment 9 Deji Akingunola 2010-07-16 10:25:06 EDT
(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.
Comment 10 Deji Akingunola 2010-07-16 11:25:39 EDT
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
>>
Comment 11 Tom Lane 2010-07-16 12:02:50 EDT
[ 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.
Comment 12 Tom Lane 2010-07-16 13:48:22 EDT
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.
Comment 13 Alfredo Pons Menargues 2010-07-19 03:11:05 EDT
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.
Comment 14 Deji Akingunola 2010-07-27 09:06:29 EDT
*** Bug 618513 has been marked as a duplicate of this bug. ***
Comment 15 Tom Lane 2010-11-15 20:08:01 EST
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.

Note You need to log in before you can comment on or make changes to this bug.