Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PolarVolume_getScanClosestToElevation_vol2bird() leads to segfault when using cluttermap #150

Closed
adokter opened this issue Jul 28, 2020 · 3 comments
Labels
Milestone

Comments

@adokter
Copy link
Owner

adokter commented Jul 28, 2020

New function PolarVolume_getScanClosestToElevation_vol2bird() leads to a segfault when selecting cluttermap elevation scans. Reverting to PolarVolume_getScanClosestToElevation() solves the issue.

@adokter adokter added the bug label Jul 28, 2020
@adokter adokter changed the title segfault when using cluttermap PolarVolume_getScanClosestToElevation_vol2bird() leads to segfault when using cluttermap Jul 28, 2020
@adokter
Copy link
Owner Author

adokter commented Jul 28, 2020

This suggests that potentially something is wrong with PolarVolume_getScanClosestToElevation_vol2bird(), which is used in elevation scan selection in Mistnet, see #148.

@adokter adokter added this to the 0.6 milestone Jul 28, 2020
adokter added a commit that referenced this issue Jul 28, 2020
@adokter
Copy link
Owner Author

adokter commented Jul 28, 2020

Reverting back to PolarVolume_getScanClosestToElevation() in 4adfaa7 fixes the issue for now.

Verified that PolarVolume_getScanClosestToElevation_vol2bird() selects the correct scan at the end of its function body, however when accessing returned object clutScan here the program crashes:

vol2bird/lib/libvol2bird.c

Lines 1989 to 1992 in 4adfaa7

//FIXME: here PolarVolume_getScanClosestToElevation_vol2bird leads to a segmentation fault. It finds the correct scan, but
//any operation here on the pointer leads to segfault...
//clutScan = PolarVolume_getScanClosestToElevation_vol2bird(clutVol,elev);
clutScan = PolarVolume_getScanClosestToElevation(clutVol,elev,0);

Need more solid fix, leaving issue open

adokter added a commit that referenced this issue Jul 28, 2020
@adokter
Copy link
Owner Author

adokter commented Jul 30, 2020

What causes the segfault, is that the pointer returned in the function body of PolarVolume_getScanClosestToElevation_vol2bird() - and which I verified points to a proper Rave scan object - is not equal to the pointer received by the function call, as it should be.

Unfortunately valgrind doesn't give good clues; the process runs normally and the pointer IS correctly returned in valgrind runs. So potentially this is a memory issue occurring somewhere different entirely. Valgrind also finds no unrecoverable memory leaks:

valgrind --leak-check=full vol2bird KCBX20180703_185917_V06
==25583== Memcheck, a memory error detector
==25583== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25583== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==25583== Command: vol2bird KCBX20180703_185917_V06
==25583== 
Loaded user configuration file 'options.conf' ...
Reading RSL polar volume with nominal time 20180703-185917, source: RAD:KCBX,PLC:BOISE,state:ID,radar_name:KCBX

==25583== 
==25583== HEAP SUMMARY:
==25583==     in use at exit: 250,148,074 bytes in 12,298 blocks
==25583==   total heap usage: 315,963 allocs, 303,665 frees, 448,826,117 bytes allocated
==25583== 
==25583== LEAK SUMMARY:
==25583==    definitely lost: 0 bytes in 0 blocks
==25583==    indirectly lost: 0 bytes in 0 blocks
==25583==      possibly lost: 0 bytes in 0 blocks
==25583==    still reachable: 250,148,074 bytes in 12,298 blocks
==25583==                       of which reachable via heuristic:
==25583==                         stdstring          : 319,918 bytes in 4,373 blocks
==25583==         suppressed: 0 bytes in 0 blocks
==25583== Reachable blocks (those to which a pointer was found) are not shown.
==25583== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25583== 
==25583== For counts of detected and suppressed errors, rerun with: -v
==25583== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant