The attached LSX has devdatimp.run that xcalls datimp (a dialog selecting a csv and then matching the columns). You will trace.prints from contents of the included csv file. The dataimport.bsi module creates a DYNSTRUCT of the select columns with the coders desired names.
This program runs in EL7 with no errors, but segfaults in Debian12 .
I've tested from A-Shell Version 7.0.1756.2 to 7.0.1768.3.
Sorry this is turning out to be difficult to pin down. One reason is the problem changes after recompilation (which I didn't recognize at first). This remains an investigation in progress, but here's my thought process at the moment...
Using the version you sent (which was compiled using compiler edit 1046 (A-Shell 7.0.1757.5), the crash occurs in the NEXT $$i statement below:
Code
0191ca FOREACH $$i IN $columns(startkey$)
0190c3 IF (fn'str_startswith(search$=.KEY($$i), substr$=startkey$) = 1) THEN
0190e0 $columns(.KEY($$i)) = .NULL
0190ec ELSE
0190f0 EXIT
0190f4 ENDIF
0190f4 NEXT $$i
I tried to drill down to the actual point of failure, but it occurs deep inside the standard template library code implementing the ordered maps. However, looking at the code more closely, it appears to commit the faux pas of manipulating the index (or more explicitly, deleting a key-value pair) from the collection being iterated. The fact that the fallout from that differs across platforms/architectures is not entirely shocking. See Writeable Iterators for a brief mention of the issue in our doc. Searching for "deleting key-value pairs while iterating a collection" will turn up some more general comments about the problem and workarounds in languages such as Python and Java.
Interestingly though, when I recompile the program I get (error 70 - invalid dynstruct reference) here...
Code
IF (fn'dataimport_iter_csv(hndl=hndl'first, iter'hndl=iter'hndl, mode=0) = 1) THEN ...
...
FUNCTION fn'dataimport_iter_csv(hndl as B3:INPUTONLY,iter'hndl as B3,mode as B1:INPUTONLY,datimp'dynx="" as DYNSTRUCT:OUTPUTONLY) as f8
That was caused by a loophole in the handling of the initialization of the DYNSTRUCT datimp'dynx to "". However, after closing that loophole, the error moves to this function...
Code
01a94e PRIVATE FUNCTION fn'dataimport_iter_csv_next_set'dynst(hndl as B3:INPUTONLY,iter'hndl as B3,$columns() as ordmap(varstr;varx),csv'ary() as x0,datimp'dynx="" as DYNSTRUCT,dummy=0 as b1:OUTPUTONLY)
01a9da MAP1 func$ ,s,128,"fn'dataimport_iter_csv_next_set'dynst()"
01aa08 MAP1 col'st ,DATAIMPORT_COLUMNS_ST
01aa08 !>> MAP2 col'st.column'ct,f,8
01aa08 !>> MAP2 col'st.label$,s,128
01aa08 !>> MAP2 col'st.field'name$,s,128
01aa08 !>> MAP2 col'st.required,BOOLF,8
01aa08 !>> MAP2 col'st.selected'col,f,8
01aa08
01aa08 XCALL FILL, datimp'dynx, ""
01aa17 FOREACH $$i IN $columns()
01aa41 col'st = $$i
01aa49 IF (col'st.selected'col > 0) THEN
01aa55 datimp'dynx.@col'st.field'name$ = csv'ary(col'st.selected'col)
01aa66 ENDIF
01aa66 NEXT $$i
01aa7c XPUTARG @datimp'dynx
01aa85 ENDFUNCTION[code]
It seems to think that datimp'dynx.@col'st'field'name$ is a reference to an uninitialized dynstruct, but it's not easy to tell if that's a valid error or not without inserting some code. It occurs to me that it might be nice if there was a variation of the .ISDEF(ds), perhaps .ISBOUND(ds) to simplify testing if dynstruct was initialized/bound to something.
I think we might be close to the bottom on this...
I decided to implement the .ISBOUND(ds) function, making it easier to insert simple traces to track the binding status of the datimp'dynx variable in your routine. The last three traces I get are before the error 70 are (with the value at the end of each line indicating the result of .ISBOUND(datimp'dynx) .)..
Code
main 2-datimp'dynx -1
func$=[fn'dataimport_iter_csv()], mode=[1], 10-datimp'dynx 0
func$=[fn'dataimport_iter_csv_next_set'dynst()], 20-datimp'dynx 0
The "main 2-datimp'dynx -1" trace shows that the datimp'dynx is bound (-1) after the call to fn'dataimport_iter_csv(), as expected. But the next trace shows it unbound (0). That code is here...
Code
01a5b2 FUNCTION fn'dataimport_iter_csv(hndl as B3:INPUTONLY,iter'hndl as B3,mode as B1:INPUTONLY,datimp'dynx="" as DYNSTRUCT:OUTPUTONLY) as f8
...
01a66b trace.print (2) func$, mode, "10-datimp'dynx", .isbound(datimp'dynx) ! [jm]
01a6d0 IF (mode = 0) THEN
...
01a7e0 ELSEIF (mode = 1) THEN
01a7f0 ch'csv = $s_ch'csv(iter'hndl)
01a7fe INPUT CSV #ch'csv, csv'ary()
01a80c IF EOF(ch'csv) THEN
01a815 XCALL FILL, datimp'dynx, ""
01a824 mode = 2
01a82c .fn = 3
01a834 ELSE
01a838 CALL fn'dataimport_iter_csv_next_set'dynst(hndl=hndl, iter'hndl=iter'hndl, $columns()=$s_columns(),csv'ary()=csv'ary(),datimp'dynx=datimp'dynx)
01a85c trace.print (2) "11-datimp'dynx", .isbound(datimp'dynx) ! [jm]
01a897 mode = 1
01a89f .fn = 2
01a8a7 ENDIF
01a8a7 XPUTARG @datimp'dynx
01a8b0 ENDIF
So we passed a bound dynstruct to fn'dataimport_iter_csv(), but it gets received as unbound (based on the trace at location 01a66b).
What happened? The :OUTPUTONLY qualifier on the function parameter list. So the dynstruct starts out again as uninitialized, and when it gets passed in that state to fn'dataimport_iter_csv_next_set'dynst(), an error occurs when that function tries to reference field level members. (Note that we don't ever get the trace at 01a85c, so the error is in that routine, specifically:
01aa62 PRIVATE FUNCTION fn'dataimport_iter_csv_next_set'dynst(hndl as B3:INPUTONLY,iter'hndl as B3,$columns() as ordmap(varstr;varx),csv'ary() as x0,datimp'dynx="" as DYNSTRUCT,dummy=0 as b1:OUTPUTONLY)
...
01ab1c trace.print (2) func$, "20-datimp'dynx", .isbound(datimp'dynx) ! [jm]
01ab6c XCALL FILL, datimp'dynx, ""
01ab7b FOREACH $$i IN $columns()
01aba5 col'st = $$i
01abad IF (col'st.selected'col > 0) THEN
01abb9 datimp'dynx.@col'st.field'name$ = csv'ary(col'st.selected'col)
01abca ENDIF
01abca NEXT $$i
01abe0 XPUTARG @datimp'dynx
01abe9 trace.print (2) func$, "20-datimp'dynx", .isbound(datimp'dynx) ! [jm]
01ac39 ENDFUNCTION
Why did it ever work? Because of compiler edit 1047 (one edit beyond the one you had previously compiled this program with)...
Quote
1. Compiler bug fixes (edit 1047):
- Specifying a default value for a parameter in a function declaration was effectively overriding the outputonly clause.
- The :outputonly attribute was making it impossible to specify that parameter by name in a DYNFUNC() call.
(This issue turned out to be complicated due to historical / legacy / compatibility factors, leading to a series of subsequent updates, one of which introduced the ++PRAGMA OVERRIDE_OUTPUTONLY feature which effectively ignores the :OUTPUTONLY qualifier so that the parameters revert to the pre-1047 behavior, i.e. acting like in/out. With that in place, I start getting the variations of the original error you reported (described in my prior post) caused by deleting members of the collection while iterating it. While that leads to a SEGFAULT under Debian 12, in Windows I managed to trap an "incompatible iterator" error running it through a debugger, both of which are consistent with the known problem in the underlying system calls.
Perhaps the compiler can be made smart enough to trap that situation as an error, but for now, you have to avoid it. And although the 7.0.1770.0 update introduces the handy .ISBOUND(ds) function, it doesn't really change the behavior of the version you have relative to this issue. So my position, at least at this moment, is to suggest that you:
Either add the ++PRAGMA OVERRIDE_OUTPUTONLY or manually remove those qualifiers from the dynstruct function parameters.
Revise the code in fn'dataimport_iter_csv_end_remove'xref() to avoid deleting items from the collection while iterating it.
I'll fix this to not do the deletion in the iteration. Could this be made a compiler error? Seems like behavior we don't want to allow as it causing Segfault.
Kyle Vaughn reported the error 70 - invalid dynstruct reference to me and as I was helping debug I ran into the segfault first.
I'm going to see if I can get the compiler to flag this today. I think I have all the necessary information. But one detail I forgot to clarify in my previous post -- the 1770.0 update contains one other related fix to avoid generating error #70 on the assignment of the default value "" to the dynstruct parameter, i.e.
Code
function fn'foo(ds="" as dynstruct:outputonly, ...)
While it's debatable whether assigning a literal to an unbound dynstruct should generate an error, (since it doesn't really make sense), this is a special case where the purpose of the assignment is purely to make the parameter optional, i.e. to provide flexibility to call the function with only the named parameters of interest. So you'll need the update in any case.
Actually, looking into this now, I can see some problems with the compiler being able to flag illegal map update operations during iteration, while allowing legal ones. The documentation (see Writeable iterators) clarifies that it's ok to update the map being iterated, as long as it doesn't affect the keys, offering this example of two ways to do it..
The first method presents multiple difficulties, since the key argument, .key($$i)) could theoretically be an ordinary string variable, impossible for the compiler to evaluate at runtime. We could require that only legal key is the .key($$i)) function as in the example, or that you always use method 2. But even with the simpler method 2, I'm not sure the compiler can rule out the possibility that the value being assigned doesn't equate to .NULL.
I suppose it could detect the most straightforward cases (i.e. ".NULL" appearing literally in the expression), i.e. not let the perfect be the enemy of the good.
I think I've successfully updated the compiler to treat an assignment of an explicit .NULL to the collection being iterated. So your sample program now triggers this error:
Code
?Illegal collection update during iteration (see Writeable Iterators) (+22685) - $columns(.KEY($$i)) = .NULL
As previously mentioned though, the compiler can't very well detect an assignment to a string variable which turns out to evaluate to .NULL at runtime.
On the runtime side, we can pick up some of those errors where the value being assigned turns out to be .NULL, provided that the lvalue is either explicitly an iterator (e.g. $$i = value$) or explicitly uses the .key() function, e.g. ($columns(.KEY($$i)) = value$). What I don't have a good solution for is the case of a generic-looking assignment, e.g. $m(key$) = value$ that happens to occur while iterating the target collection. That would require sub-classing the collection classes to add some kind of iteration-in-progress state variable, which seems doable but more potentially disruptive than I want to get into right now. The new compiler and runtime tests though should cover nearly all of the exposure though, especially if you stick with using the explicit iterator when making assignments to a collection during iteration.
I still have a lot of testing to do though, to make sure this didn't have side effects with the MLIST and GRIDMAP collections. Hopefully I'll be able to post an beta update this afternoon.
Are you sure you removed the :OUTPUTONLY from the fn'dataimport_iter_csv_next_set'dynst() function declaration ...
Code
019110 PRIVATE FUNCTION fn'dataimport_iter_csv_next_set'dynst(hndl as B3:INPUTONLY,iter'hndl as B3,$columns() as ordmap(varstr;varx),csv'ary() as x0,datimp'dynx="" as DYNSTRUCT,dummy=0 as b1:OUTPUTONLY)
You either need to do that, or add a ++PRAGMA OVERRIDE_OUTPUTONLY statement somewhere. The reason you didn't get the error previously (under -el7) was that the earlier version was in fact ignoring the :OUTPUTONLY modifier when there was a default value, but we subsequently decided that didn't make sense.
PRIVATE FUNCTION fn'dataimport_iter_csv_next_set'dynst(hndl as HANDLE:INPUTONLY,iter'hndl as ITER_HANDLE,$columns() as ordmap(varstr;varx),csv'ary() as x0,datimp'dynx="" as DYNSTRUCT,dummy=0 as DUMMY:OUTPUTONLY)
Also happens when
Code
PRIVATE FUNCTION fn'dataimport_iter_csv_next_set'dynst(hndl as HANDLE:INPUTONLY,iter'hndl as ITER_HANDLE,$columns() as ordmap(varstr;varx),csv'ary() as x0,datimp'dynx as DYNSTRUCT)
Something is out of sync between us. I started over with the original devdatimp.lsx you emailed (763-775-201-752), and recompiled it under 7.0.1770.0. Both Windows and Debian 12 generate the same compil error (?Illegal collection update during iteration (see Writeable Iterators) (+22683) - $columns(.KEY($$i)) = .NULL) in this routine...
Code
018fde PRIVATE FUNCTION fn'dataimport_iter_csv_end_remove'xref(hndl as B3:INPUTONLY,iter'hndl as B3,$columns() as ordmap(varstr;varx),dummy=0 as b1:OUTPUTONLY)
019043 MAP1 func$ ,s,128,"fn'dataimport_iter_csv_end_remove'xref()"
019072 MAP1 startkey$ ,s,0
019072
019072 startkey$ = iter'hndl USING "######Z"
019084 startkey$ += "-"
019090 FOREACH $$i IN $columns(startkey$)
0190c3 IF (fn'str_startswith(search$=.KEY($$i), substr$=startkey$) = 1) THEN
0190e0 $columns(.KEY($$i)) = .NULL
0190ec ELSE
0190f0 EXIT
0190f4 ENDIF
0190f4 NEXT $$i
01910a ENDFUNCTION
That's due to the new compile feature(?) to treat obvious deletions from an ordmap during iteration as compile errors rather than wait for them to show up as some kind of segfault or other unexpected runtime behavior. To work around the compiler complaint (without worrying about what it's going to do to the algorithm logic), I just changed the offending statement to:
Code
0190e0 $columns(.KEY($$i)) = "" ! [jm] .NULL
(Setting the value to "" leaves the key-value pair in the index, avoiding the problems with changing the index during iteration.) The recompiled RUN file hash is 771-517-632-117. Running it results in this trace:
Code
TESTDATIMP: - datimp'dynx.column is not defined
And this error:
Code
[p13719-1]<DEVDATIMP:1aa55> Trapped Basic Error #70 (Invalid dynstruct reference) at location counter &h1AA55, last proc/func: fn'dataimport'bsi_'_dataimport_iter_csv_next_set'dynst
[p13719-1]<DEVDATIMP:1aa55> Call stack trace, from program DEVDATIMP :
From loc 1b78c, Func() @1a53e
From loc 1a75f, Call Proc() @1a94e
The error #70 problem there is due to the :OUTPUTONLY qualifier in the following function (upstream of the one you modified above), which causes the datimp'dynx dynstruct to get reinitialized to "", wiping out it's previous binding...
Code
FUNCTION fn'dataimport_iter_csv(hndl as B3:INPUTONLY,iter'hndl as B3,mode as B1:INPUTONLY,datimp'dynx="" as DYNSTRUCT:OUTPUTONLY) as f8
If I remove the :OUTPUTONLY qualifier on the DYNSTRUCT and recompile (generating 204-100-215-514), it runs without error. Or, to take the simpler approach, putting the :OUTPUTONLY qualifier back the way it was but adding ++PRAGMA OVERRIDE_OUTPUTONLY results in 115-622-043-726 and also runs without error.
I'm ignoring here the difference between what you wanted to do in the fn'dataimport_iter_csv_end_remove'xref() function (deleting items from the map) vs just assigning their values to "". If you really wanted to remove items from the map in that function, you'd have to come up with an alternate method, probably involving identifying the keys to be removed during the iteration, but then removing them outside the FOREACH iteration loop.
If your code has diverged from the version you sent me last week, making the above hard to match up to yours, another suggestion would be to use the new .ISBOUND(ds) function in a trace to identify where the dynstruct loses its binding.
I fixed the delete while iterating issue but missed the change to fn'dataimport_iter_csv(). Removing the OUTPUTONLY from there does resolve the 70 - invalid dynstruct reference issue.
Maybe this needs to be in a separate post, but we feel that OUTPUTONLY should be valid with DYNSTRUCT. They should behave as close to DEFSTRUCTS as possible. That means they should be bound to the local variable and be empty just like a DEFSTRUCT is.
How do-able is that? Do you disagree that's not desirable behavior?
If that is not the desired behavior, it should be a compile error to use OUTPUTONLY with a Dynstruct.
I'm not sure I understand your position. The :OUTPUTONLY qualifier is perfectly valid with a DYNSTRUCT param, but only makes sense if you don't want the caller's DYNSTRUCT value, or its binding, to be passed in. That doesn't interfere with your ability to bind the structure within the function and pass it back. If you wanted to bind the structure in the calling routine and pass it in to the function, you can do that by removing the :OUTPUTONLY. Here's an example showing both variations...
Code
defstruct ST_FOO
map2 bar,s,10
endstruct
map1 FOO, dynstruct
call fn'foo'bind(foo=FOO) ! passing un-bound FOO
! comes back bound and assigned
? "After call to fn'foo'bind(), FOO.bar = "; FOO.bar
call fn'foo2(foo=FOO) ! passing bound FOO
end
function fn'foo'bind(foo="" as dynstruct:outputonly)
map1 stfoo, ST_FOO
.bindstruct foo, stfoo
foo.bar = "Martini"
xputarg @foo
endfunction
function fn'foo2(foo="" as dynstruct)
? "in fn'foo2(), foo.bar = "; foo.bar
endfunction
Code
.run dyn4
After call to fn'foo'bind(), FOO.bar = Martini
in fn'foo2(), foo.bar = Martini
Note that the ="" default value is irrelevant in the above case; I added it just to illustrate that it doesn't interfere. So what am I missing?
That still doesn't behave like a DEFSTRUCT does with OUTPUTONLY. Yes, we want it to be bound when passed, but allow OUTPUTONLY for the dynstruct to be bound in the caller, but have no value. That's exactly what happens for DEFSTRUCT with OUTPUTONLY.
Per our phone conversation (after my post above), we've agreed that the :OUTPUTONLY qualifier should only disable the passing in of values bound to the DYNSTRUCT, but not the binding of the DYNSTRUCT to DEFSTRUCT. Although that wouldn't affect the example above, this modified version illustrates where it would come into play, in fn'foo3() ...
Code
defstruct ST_FOO
map2 bar,s,10
endstruct
map1 FOO, dynstruct
call fn'foo'bind(foo=FOO) ! passing un-bound FOO
! comes back bound and assigned
? "After call to fn'foo'bind(), FOO.bar = "; FOO.bar
call fn'foo2(foo=FOO) ! passing bound FOO
call lfn'foo3(foo=FOO)
end
function fn'foo'bind(foo="" as dynstruct:outputonly)
map1 stfoo, ST_FOO
.bindstruct foo, stfoo
foo.bar = "Martini"
xputarg @foo
endfunction
function fn'foo2(foo="" as dynstruct)
? "in fn'foo2(), foo.bar = "; foo.bar
endfunction
function fn'foo3(foo="" as dynstruct:outputonly)
? "in fn'foo2(), foo.bar = "; foo.bar ! this would be empty/null due to :outputonly
foo.bar = "Margarita" ! but this would work, since the foo struct binding unaffected by the :outputonly
endfunction
It's on the to-do list, but probably won't be released until after this weekend.
The update related to detecting the deleting of elements during iteration seems to have an issue. I was able to reproduce with the code below. A-Shell 7.0.1770.4 EL7
Code
++PRAGMA PRIVATE_BEGIN
PRIVATE DIMX $ordership'pallet'item_fk_order_pallet_iter_dyn'key,ordmap(varstr;varstr)
++PRAGMA PRIVATE_END
MAIN'ROUTINE:
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("1-1") = "_"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("1-2") = "_"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("2-1") = "_"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key("2-2") = "_"
CALL fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect(hndl=1)
END
!-------------------------------------------------------------------------
!Function: fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect()
! delete all dyn'key elements for given handle
!
!Parameters:
!--------------------------
! hndl [ITER_HANDLE, i/o] - variable with handle value
!Privates:
!--------------------------
! $ordership'pallet'item_fk_order_pallet_iter_dyn'key()
!-------------------------------------------------------------------------
FUNCTION fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect(hndl as f8:INPUTONLY,dummy=0 as b1:OUTPUTONLY)
MAP1 func$ ,s,0,"fn'ordership'pallet'item_idx_fk_order_pallet_iter_dyn'key_garbage'collect()"
DIMX $gc ,ordmap(varstr;varstr) ! key by dyn'key
trace.print " " + func$ + " hndl=["+hndl+"] "
FOREACH $$i IN $ordership'pallet'item_fk_order_pallet_iter_dyn'key(hndl)
!IF (fn'str_startswith(.key($$i), hndl) = TRUE) THEN
IF VAL(.KEY($$i)[1;1]) = hndl THEN
trace.print " " + func$ + " GATHER .key($$i)=["+.key($$i)+"] val=["+edit$(STR($$i), 40)+"]"
$gc(.key($$i)) = ""
ELSE
EXIT
ENDIF
NEXT $$i
FOREACH $$i IN $gc()
trace.print " " + func$ + " DELETE .key($$i)=["+.key($$i)+"] val=["+edit$(STR($$i), 40)+"]"
$ordership'pallet'item_fk_order_pallet_iter_dyn'key(.key($$i)) = .NULL
NEXT $$i
ENDFUNCTION
The operation of deleting the element in the second loop causes a BASIC error.
I'm afraid you've found a crack in the digital firmament. The runtime time detection that was added in order to be able to report an error instead of running the risk of a segmentation fault was far from perfect. It fails to detect workarounds, like assigning .key($$i) to a variable and then using it as the key, or coping .NULL to a variable and using it to delete the key-value pair. At the time, I figured it was better than nothing. But obviously in this case, it's worse than nothing, since your key-value deletion during iteration of a different map is perfectly safe. I have to think about whether it's practical for the runtime system to detect that the map from which the key-value pair is being deleted is not the one being iterated. It may be best to just rely on the compiler to try to flag them before the runtime system gets a chance to see them.
In the meantime though, the workaround is simple enough (just copy the .key($$i) value to a variable and use it for the deletion) ...
Code
map1 key$, s, 20
...
FOREACH $$i IN $gc()
key$ = .key($$i)
$ordership'pallet'item_fk_order_pallet_iter_dyn'key(key$)) = .NULL
NEXT $$i
Although this is totally off the subject, for what it's worth, I'd like to make sure that you are aware of a couple of syntactic shortcuts related to your code:
The first is that the auto-defined symbol ABC_CURRENT_ROUTINE$ is automatically set to the name of the current function, so there's no real need for your func$ variable definition. (I realize that it's probably your code generator doing this, so weren't not talking about saving wear and tear on your fingers, but it might make the code slightly cleaner to look at.)
The second is that the trace.print statement will automatically output the names of variables specified, along with their values, so for example, instead of :
Code
trace.print " " + func$ + " hndl=["+hndl+"] "
you could instead use
Code
trace.print ABC_CURRENT_ROUTINE$, hndl
The output of the second version is virtually identical to the first, e.g.
Thanks for the reply. You are correct that this is templated code. So, that is where the func$ mapping is from. I am glad you mentioned the keyword though as I was unaware or had forgotten about it as it is common for us to always map the func$ variable and set it to either a string literal of the function name or .LAST_ROUTINE if it is in a program where we can count on the pragma TRACK_LAST_ROUTINE being enabled. As for the detection, just let us know what you decide.
I figured out a way to make the check for an illegal deletion from a collection during iteration more precise. But as it would close off the back door workaround, so I need to be certain that it isn't going to block any otherwise legal/legitimate operations. Figure on an update in a couple of days.
Ok, here's a new-and-improved test version (7.0.1770.5) which implements the test (for an attempt to delete a collection element while iterating the collection) at a lower level, where it won't be fooled by code like the example above. But note that it also won't be fooled by my suggested workaround of using another variable in place of the .key($$i) or .NULL references.
It still issues that same error 67 (?Invalid collection operation or reference), which perhaps isn't as clear and precise as it could be (as opposed to, say, "?Illegal attempt to delete an element of collection during iteration"), but I wasn't sure it was worth christening a new error code. For now, let me just repeat that this is a limitation of the underlying Standard Template Library implementation of collections, not an ASB issue per se.
