Project

General

Profile

Bug #9096

memory corruption in monotone_hermite_set()

Added by James C. McPherson over 7 years ago.

Status:
Fixed
Priority:
Medium
Category:
General
Start date:
11/28/2012
Due date:
% Done:

100%

Estimated time:
1.00 h
Affected Version:
1.1.0
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I've been beating up on the 1.1 tarball so I could make
the Solaris package, and came across a rather nasty memory
corruption problem.

My sanity check of the build died when I clicked on any
image in my library, with this info:

$ mdb /opt/darktable/bin/darktable

:r -v

[mipmap_cache] cache is empty, file `/home/jmcp/.cache/darktable/mipmaps-2c30cb4285311a3eb3dd7b0daf9b4c5f8f666440' doesn't exist
umem allocator: redzone violation: write past end of buffer
buffer=3f687a60 bufctl=3f689178 cache: umem_alloc_16
previous transaction on buffer 3f687a60:
thread=4 time=T-0.003466117 slab=3f635d30 cache: umem_alloc_16
libumem.so.1'umem_cache_alloc_debug+0x157
libumem.so.1'umem_cache_alloc+0x157
libumem.so.1'umem_alloc+0xd0
libumem.so.1'malloc+0x2d
libumem.so.1'calloc+0x63
libdarktable.so'monotone_hermite_set+0x7e
libdarktable.so'interpolate_set+0x32
libdarktable.so'CurveDataSample+0x48e
libbasecurve.so'commit_params+0x145
libbasecurve.so'init_pipe+0x65
libdarktable.so'dt_iop_init_pipe+0x3a
libdarktable.so'dt_dev_pixelpipe_create_nodes+0xeb
libdarktable.so'dt_imageio_export_with_flags+0x170
libdarktable.so'_init_8.isra.8+0x1a7
libdarktable.so'dt_mipmap_cache_read_get+0x449
umem: heap corruption detected
stack trace:
libumem.so.1'umem_err_recoverable+0x42
libumem.so.1'umem_error+0x510
libumem.so.1'umem_free+0x11b
libumem.so.1'process_free+0x57
libumem.so.1'free+0x1e
libdarktable.so'CurveDataSample+0x54a
libbasecurve.so'commit_params+0x145
libbasecurve.so'init_pipe+0x65
libdarktable.so'dt_iop_init_pipe+0x3a
libdarktable.so'dt_dev_pixelpipe_create_nodes+0xeb
libdarktable.so'dt_imageio_export_with_flags+0x170
libdarktable.so'_init_8.isra.8+0x1a7
libdarktable.so'dt_mipmap_cache_read_get+0x449
libdarktable.so'dt_image_load_job_run+0x4b
libdarktable.so'dt_control_run_job+0x21c
libdarktable.so'dt_control_work+0x41
libc.so.1'_thrp_setup+0x9d
libc.so.1'_lwp_start+0x0
mdb: stop on SIGABRT

libumem is a memory allocation library which provides some protection
for your application and is very useful to help nail down errors like
this.

I eventually tracked the problem to this part of monotone_hermite_set
(in src/common/curve_tools.c):

440 for (i=0; i<n; i++)
441 {
442 if (fabs(delta[i]) < EPSILON)
443 {
444 m[i] = 0.0f;
445 m[i+1] = 0.0f;
446 }
447 else
448 {
449 const float alpha = m[i]/delta[i];
450 const float beta = m[i+1]/delta[i];
451 const float tau = alpha*alpha+beta*beta;
452 if (tau > 9.0f)
453 {
454 m[i] = 3.0f*alpha*delta[i]/sqrtf(tau);
455 m[i+1] = 3.0f*beta*delta[i]/sqrtf(tau);
456 }
457 }
458 }

'm' is allocated to be 'n' * sizeof(float). Which is
great until line 455 - when i = n-1, we then blat a number
into m[n], which exceeds the limit of the array.

Changing #424 to be an 'n+1' allocation makes the problem
go away.

424 m = (float *)calloc(n+1,sizeof(float));

On a tangent (haha), I believe it's more efficient for the
variables alpha, beta and tau to be declared outside the
for loop so that we avoid possible stupidity from the compiler
and setup/teardown costs. Not anywhere near as important
as line 424, however.


Related issues

Related to darktable - Bug #8903: crash when manipulating base or tone curve on OS XFixed09/02/2012

History

#1 Updated by James C. McPherson over 7 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

I got my commit comment wrong (referred to 9906 rather than 9096).

This issue is fixed in:

Also available in: Atom PDF

Go to top