Hi all, 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. James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcpdotcom.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel