Hi Matt,
Should not the plan created at smurf_fts2_spectrum.c:574 be
destroyed prior to the end of the "j" loop started at line 486? On the
face of it, it looks like a new plan is created for each pass through
the "j" loop, but only the last created plan is destroyed (i.e. once
the "j" loop has been left), leaving all the other plans still
allocated.
David
On 2 May 2014 01:59, Sherwood, Matt <[log in to unmask]> wrote:
> Hi All,
>
> I have run into a memory release issue in smurf_fts2_spectrum.c when invoked
> through the ORAC-DR REDUCE-FTS_SCAN recipe's
> _FTS2_FORM_SPECTRUM_FROM_INTERFEROGRAM_ primitive. When reducing a certain
> observation having multiple scans, each spectrum generated increases the
> runtime memory footprint until (in the worst case) all available memory is
> consumed.
>
> I’ve run the code through valgrind and can see a major difference in the
> problematic case, but I’m not sure yet why it’s happening.
>
> Here is the most interesting part of valgrind’s report in the problematic
> case:
>
> ==0000== 86,685,936 bytes in 129 blocks are possibly lost in loss record 757
> of 761
> ==0000== at 0x4C2B3F8: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==0000== by 0x580094: fftw_malloc_plain (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x644254: awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x58022D: fftw_plan_awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x58022D: fftw_plan_awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x644E2B: awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x58022D: fftw_plan_awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57F4E2: fftw_mkapiplan (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FF81: fftw_plan_many_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FC48: fftw_plan_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FBF2: fftw_plan_dft_1d (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x44A04C: smurf_fts2_spectrum (smurf_fts2_spectrum.c:574)
> ==0000==
> ==0000== 372,600,000 bytes in 276 blocks are possibly lost in loss record
> 758 of 761
> ==0000== at 0x4C2B3F8: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==0000== by 0x580094: fftw_malloc_plain (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x644276: awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x58022D: fftw_plan_awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x58022D: fftw_plan_awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x644E2B: awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x58022D: fftw_plan_awake (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57F4E2: fftw_mkapiplan (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FF81: fftw_plan_many_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FC48: fftw_plan_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FBF2: fftw_plan_dft_1d (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x44A04C: smurf_fts2_spectrum (smurf_fts2_spectrum.c:574)
> ==0000==
> ==0000== 1,097,093,672 (18,432 direct, 1,097,075,240 indirect) bytes in 768
> blocks are definitely lost in loss record 761 of 761
> ==0000== at 0x4C2B3F8: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==0000== by 0x580094: fftw_malloc_plain (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57F474: fftw_mkapiplan (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FF81: fftw_plan_many_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FC48: fftw_plan_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FBF2: fftw_plan_dft_1d (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x44A04C: smurf_fts2_spectrum (smurf_fts2_spectrum.c:574)
> ==0000== by 0x40F3EC: smurf_mon (smurf_mon.c:355)
> ==0000== by 0x40F537: dtask_wrap_ (dtask_wrap.c:8)
> ==0000== by 0x40E7A4: dtask_applic_ (dtask_applic.f:75)
> ==0000== by 0xF4AC052: dtask_obeydcl_ (dts_obeydcl.f:161)
> ==0000== by 0xF4AA785: dtask_dcltask_ (dts_dcltask.f:153)
> ==0000==
> ==0000== LEAK SUMMARY:
> ==0000== definitely lost: 18,508 bytes in 770 blocks
> ==0000== indirectly lost: 1,097,075,480 bytes in 32,628 blocks
> ==0000== possibly lost: 459,335,889 bytes in 1,300 blocks
> ==0000== still reachable: 1,620,088 bytes in 643 blocks
> ==0000== suppressed: 0 bytes in 0 blocks
> ==0000== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==0000== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==0000==
> ==0000== For counts of detected and suppressed errors, rerun with: -v
> ==0000== Use --track-origins=yes to see where uninitialised values come from
> ==0000== ERROR SUMMARY: 105740 errors from 715 contexts (suppressed: 2 from
> 2)
>
>
> In a control case, there are still issues, but they are much smaller:
>
> ==0000== 1,783,936 (17,376 direct, 1,766,560 indirect) bytes in 724 blocks
> are definitely lost in loss record 729 of 729
> ==0000== at 0x4C2B3F8: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==0000== by 0x5800E4: fftw_malloc_plain (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57F4C4: fftw_mkapiplan (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FFD1: fftw_plan_many_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FC98: fftw_plan_dft (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x57FC42: fftw_plan_dft_1d (in
> /home/matt/software/star/bin/smurf/smurf_mon)
> ==0000== by 0x44A05C: smurf_fts2_spectrum (smurf_fts2_spectrum.c:574)
> ==0000== by 0x40F3EC: smurf_mon (smurf_mon.c:355)
> ==0000== by 0x40F537: dtask_wrap_ (dtask_wrap.c:8)
> ==0000== by 0x40E7A4: dtask_applic_ (dtask_applic.f:75)
> ==0000== by 0xF4AC052: dtask_obeydcl_ (dts_obeydcl.f:161)
> ==0000== by 0xF4AA785: dtask_dcltask_ (dts_dcltask.f:153)
> ==0000==
> ==0000== LEAK SUMMARY:
> ==0000== definitely lost: 17,452 bytes in 726 blocks
> ==0000== indirectly lost: 1,766,800 bytes in 11,594 blocks
> ==0000== possibly lost: 49,913 bytes in 894 blocks
> ==0000== still reachable: 234,872 bytes in 635 blocks
> ==0000== suppressed: 0 bytes in 0 blocks
> ==0000== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==0000== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==0000==
> ==0000== For counts of detected and suppressed errors, rerun with: -v
> ==0000== Use --track-origins=yes to see where uninitialised values come from
> ==0000== ERROR SUMMARY: 595 errors from 595 contexts (suppressed: 2 from 2)
>
>
> This (smurf_fts2_spectrum.c:574) line creates an fftw plan, which is later
> destroyed in line 615, or 653. I noticed some funny code in the second
> fftw_destroy_plan line that was trying to avoid a redundant destroy call,
> but this should be unnecessary, so I tried removing the safeguard, but it
> didn’t help.
>
> Any insights would be appreciated.
>
> Cheers,
> Matt
> --------------------------------------------------------------------------------------------
> Matt Sherwood Research Associate
> Institute for Space Imaging Science (ISIS)
> Physics & Astronomy Department University of Lethbridge
> Lethbridge, Alberta, Canada T1K 3M4
> Ph: 1 (403) 332-4072 Cell: 1 (587) 220-0880
> Web: JCMT SCUBA-2 FTS Email: [log in to unmask]
> --------------------------------------------------------------------------------------------
>
>
>
>
|