Assertion failure handling *equate

[Juan Corrin]

netbits.c:381: assert(!fixed(stn)) failed

cavern: error: Bug in program detected! Please report this to the authors

Survex processing works on single files and smaller groups but failed (for the first time ever!) on a file with over 650 entries.

[Olly Betts]

Based on the source location it's something to do with *equate but I'm not sure what's going on.

Are you able to share the data so I can reproduce and debug?

If not, what was the last release this processes with? Then maybe I can narrow down to a likely change.

[Olly Betts]

After peering at the code some more, I managed to trigger the same assertion with this simple input:

*fix 1 0 0 0
*fix 2 0 0 0
*equate 1 2

However the code path this requires us to take emits a warning:

trac143.svx:3: warning: Equating two equal fixed points: “2” and “1”
 *equate 1 2

The change where that starts failing is bf9faf6794f8f92774ef21f4d3904c805a6612b4 which was in 1.4.13. That change added this assertion though. It looks like that assertion shouldn't be there (it's also asserted inside the conditional block below, which does make sense).

However I don't see how we can have that assertion fail without triggering this warning, so I'm confused by your .log not having the warning.

[Juan Corrin]

Thanks for the quick response. I can't remember which version I updated from (across all the laptops) - at least an early 2024 version - 1.4.6? Anyway, a zipped cleaned up version of the Matienzo Survey Survex folders should be attached (8.4Mb). In the "scenarios" folder, the crashing script is all/all.svx. One that completes (with 1 warning) is 4valleys/4valleys.svx. Another (random) success is Mistletoe area/Mistletoe-minimum.svx. Upload failed. What's the best way to get the zip to you?

[Olly Betts]

You can email it to me (olly@).

I have managed to come up with an example which triggers the assertion without the warning:

*fix 1 0 0 0
1 1a 1 0 0
2 2a 1 0 0
2 2b 1 0 0
2 2c 1 0 0
2 2d 1 0 0
*equate 1 2

This one isn't exactly the same cause. I've not got to the bottom of it yet, but I think it'd still be useful to try with your data too in case it's a different case again.

[Olly Betts]

Thanks for the data, now successfully received and tested. Based on you attaching all.log I tried processing scenarios/all/all.svx which seemed the right guess.

There are some unrelated errors due to changes since the version you were using:

scenarios/all/../../3973/3973.svx:13:3: error: “all.3973.4” can’t be both a station and a survey
 4 4.1 151 -2 12.7
   ^
scenarios/all/../../3973/3973.svx:14:3: error: “all.3973.4” can’t be both a station and a survey
 4 4.2 75 11 7.0
   ^
scenarios/all/../../3973/3973.svx:15:3: error: “all.3973.4” can’t be both a station and a survey
 4 4.3 174 -4 7.3
   ^
scenarios/all/../../3973/3973.svx:16:3: error: “all.3973.4” can’t be both a station and a survey
 4 4.4 129 -32 7.8
   ^
scenarios/all/../../3973/3973.svx:17:3: error: “all.3973.4” can’t be both a station and a survey
 4 4.5 0 90 5.4
   ^

This was never meant to be allowed and didn't actually work properly, but the existing error for it failed to trigger in some cases. The simplest fix is probably just to use a different character instead of . for those few legs, e.g.:

*flags splay
4 4_1 151 -2 12.7
4 4_2 75 11 7.0
4 4_3 174 -4 7.3
4 4_4 129 -32 7.8
4 4_5 0 90 5.4
*flags not splay

You could instead tell Survex that . is a station character and not the level separator here. The downside of doing this is that it won't then be the separator character used in the .3d file, which means that Survex < 1.4.6 (and anything else which reads .3d files and hasn't been updated) may not properly load your .3d files. You'll also see a different separator used in places which show the full station name in aven, and you would get all:3973:4.1 so that the name can be parsed unambiguously to get the survey levels, but that applies to all stations, so you also get all:3961-nicanor:19a, etc:

*flags splay
*set separator :
*set names .
4 4.1 151 -2 12.7
4 4.2 75 11 7.0
4 4.3 174 -4 7.3
4 4.4 129 -32 7.8
4 4.5 0 90 5.4
*flags not splay

You can also make these splays to anonymous stations (though that may be undesirable if the survey notes use 4.1 and you want to keep the data as close to the notes as possible) - note there's then no need to explicitly set the splay flag as that's implicit in a leg to anonymous station ..:

4 .. 151 -2 12.7
4 .. 75 11 7.0
4 .. 174 -4 7.3
4 .. 129 -32 7.8
4 .. 0 90 5.4

The other error is only in the development version currently, but there cavern actually parses *team lines. Mostly it just emits a warning if these fail to parse, but mismatched quotes are an error:

scenarios/all/../../4468/4468.svx:5:34: error: Missing "
 *TEAM  "Harry Long and John Clark
                                  ^

The documented syntax is one *team per person:

Syntax
       *team <person> [<role>...]

Example:
   
       *team "Nick Proctor" compass clino tape
       *team "Anthony Day" notes pictures tape
       *team Wookey assistant
       ; Role not recorded
       *team "Olly Betts"

so that should really be:

*TEAM  "Harry Long"
*TEAM  "John Clark"

(I should probably adjust this error to be a warning so as not to break processing existing datasets.)

There are also a lot of warnings due to other *TEAM lines which don't match the documented syntax and/or use roles that aren't in the list of recognised roles (which is aligned with Therion's team command) - for example:

scenarios/all/../../0733/0733-16-06.svx:3:37: warning: Unknown team role “disto”
 *TEAM  "Pete O'Neill" compass clino disto "James Carlisle" notes
                                     ^~~~~

This should be split into two *team commands and use length instead of disto:

*TEAM  "Pete O'Neill" compass clino length
*TEAM  "James Carlisle" notes

[Olly Betts]

Fixed by 9b1d5fc4dc65afe887843cc6df5238ef630b79e8.

(I should probably adjust this error to be a warning so as not to break processing existing datasets.)

I've also addressed this in 62be3eea2768d44b8cd9a598ae944ae31d25cff1.

[Juan Corrin]

Thanks Olly. I'll eagerly wait for 1.4.17 to be announced. Is there a straightforward link to download it now?

[Olly Betts]

Is there a straightforward link to download it now?

I guess you mean for Microsoft Windows?

If you have a github account, there are automatic builds you can get from here:

​https://github.com/ojwb/survex/actions

Click on the latest green run and scroll to the end and there should be "microsoft-windows-installer" with a download link. However they are set to be retained there for only one day (because they are large and there's a limited amount of storage; also they're mainly exposed to allow people to test specific things rather than as a replacement for releases).

I'm intending to make a new release this week though.

[Juan Corrin]

Excellent - I can load it into laptops before the Easter expedition. Thanks for your speedy help!