Get Profile Segfault

[ada-foss]

Sometimes, telling LAG to get a profile causes a segfault. This rarely seems to happen when LAG has recently been loaded. So, at a guess, at least 5 profiles need to be taken before there is a risk of this.

Could still be a race-condition. Alternatively I would look at where the memory for the profile is allocated and deallocated.

[ada-foss]

Can't reproduce by mashing space and changing the profile and zooming all at the same time like crazy. I must've utilised the get-profile function about as much as I would in a day of normal LAG usage, and I usually get this error at least once a day when I'm dealing with a lot of LiDAR.

Must be something to do with regular usage outside of just use of zoom and changing and retrieving profiles, since any race conditions should be aggravated by stress testing them in this way. Will be running a debugging version of LAG under gdb for normal use for a few days to see if I can capture this bug.

[ada-foss]

It has been suggested that this is less likely to happen when fetching a new profile having used the "v" key, than when drawing a fresh profile.

[ada-foss]

"v" hotkey uses old, supposedly redundant, code whereby loadprofile is called from the same thread. This locks up the UI, of course, but is evidently more threadsafe.

[ada-foss]

This has been resolved now by making clicking and hotkeys follow the same kind of procedure, which is ultimately a little slower but absolutely solid in terms of reliability. Ideally thread safety would be implicit, in future we need to look at making that the case rather than opening up new developments to this hazard.