Disable the use of memory-mapped files by default when opening tiff files.

[andywolk]

No description provided.

[coppice-git]

What is the purpose of this change?

[andywolk]

@coppice-git We see a lot of crashes when TIFFSetDirectory is called. This is an example for t38_terminal_send_timeout()

Core was generated by `/usr/local/freeswitch/bin/freeswitch -c -nonat -elegant-term'.
Program terminated with signal SIGBUS, Bus error.
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:326
326     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
[Current thread is 1 (Thread 0x7f7e22ea8700 (LWP 97))]
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:326
#1  0x00007f7e37704bb1 in TIFFAdvanceDirectory (tif=tif@entry=0x7f7e14db7400, nextdir=nextdir@entry=0x7f7e22ea6090, off=off@entry=0x0) at tif_dir.c:1462
#2  0x00007f7e37707740 in TIFFSetDirectory (tif=0x7f7e14db7400, dirn=<optimized out>) at tif_dir.c:1626
#3  0x00007f7e37d10559 in t4_tx_next_page_has_different_format (s=0x7f7e12d88aa8) at t4_tx.c:1619
#4  0x00007f7e37ce5801 in check_next_tx_step (s=0x7f7e12d88aa8) at t30.c:790
#5  0x00007f7e37cf2eb0 in t30_front_end_status (user_data=0x7f7e12d88aa8, status=0) at t30.c:7017
#6  0x00007f7e37d054ff in front_end_status (s=0x7f7e12d88aa8, status=0) at t38_terminal.c:149
#7  0x00007f7e37d07300 in stream_hdlc (s=0x7f7e12d88aa8) at t38_terminal.c:1041
#8  0x00007f7e37d07712 in t38_terminal_send_timeout (s=0x7f7e12d88aa8, samples=160) at t38_terminal.c:1188
#9  0x00007f7e22eb56a4 in timer_thread_run (thread=0x7f7e339b62b8, obj=0x0) at mod_spandsp_fax.c:231
#10 0x00007f7e39267f74 in dummy_worker (opaque=0x7f7e339b62b8) at threadproc/unix/thread.c:151
#11 0x00007f7e38da7fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#12 0x00007f7e3895d4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

That's another one for udptl_rx_packet() :

#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:326
#1  0x00007f3591246bb1 in ?? () from /usr/lib/x86_64-linux-gnu/libtiff.so.5
#2  0x00007f3591249740 in TIFFSetDirectory () from /usr/lib/x86_64-linux-gnu/libtiff.so.5
#3  0x00007f3591853d1c in t4_tx_start_page (s=0x7f3566443aa8) at t4_tx.c:2473
#4  0x00007f3591826e14 in tx_start_page (s=0x7f3566443aa8) at t30.c:527
#5  0x00007f35918308f2 in process_state_iv_pps_q (s=0x7f3566443aa8, msg=0x7f3566458498 "\377\023\214", len=3) at t30.c:4986
#6  0x00007f3591831eab in process_rx_control_msg (s=0x7f3566443aa8, msg=0x7f3566458498 "\377\023\214", len=3) at t30.c:5621
#7  0x00007f359183483f in t30_hdlc_accept (user_data=0x7f3566443aa8, msg=0x7f3566458498 "\377\023\214", len=3, ok=1) at t30.c:6795
#8  0x00007f3591847547 in hdlc_accept_frame (s=0x7f3566443aa8, msg=0x7f3566458498 "\377\023\214", len=3, ok=1) at t38_terminal.c:158
#9  0x00007f3591847f0f in process_rx_data (t=0x7f35664583c0, user_data=0x7f3566443aa8, data_type=0, field_type=4, buf=0x0, len=0) at t38_terminal.c:499
#10 0x00007f3591840c4a in t38_core_rx_ifp_stream (s=0x7f35664583c0, buf=0x7f356d57778b "\300\001@", len=3, log_seq_no=105) at t38_core.c:652
#11 0x00007f3591840ee6 in t38_core_rx_ifp_packet (s=0x7f35664583c0, buf=0x7f356d57778b "\300\001@", len=3, seq_no=105) at t38_core.c:750
#12 0x00007f357ea0478b in udptl_rx_packet (s=0x7f35663ce8e8, buf=0x7f356d577788 "", len=15) at udptl.c:354

TIFF handle looks broken internally:

(gdb) frame 1
#1  0x00007f7e37704bb1 in TIFFAdvanceDirectory (tif=tif@entry=0x7f7e14db7400, nextdir=nextdir@entry=0x7f7e22ea6090, off=off@entry=0x0) at tif_dir.c:1462
1462    tif_dir.c: No such file or directory.
(gdb) p tif->tif_base
$1 = (uint8 *) 0x7f7e040d6000 <error: Cannot access memory at address 0x7f7e040d6000>

So we are thinking that disabling mmap functionality in libtiff should help.

[andywolk]

 libtiff5 (4.1.0+git191117-2~deb10u2)

[andywolk]

@coppice-git any thoughts on this?

[coppice-git]

This change seems to be hiding a problem, rather than fixing it. If that works for you as a temporary patch, that's great. However, the root problem needs to be addressed. Also, disabling memory mapped files is likely to hurt performance. From the traceback that was posted one failure is in a timer thread, and one is in a data received thread. I wonder if the problem is a thread locking issue?