🐛 Stata crashes on command execution

[Sergiy Radyakin]

The following example demonstrates a sequence of commands that when executed crash Stata without possibility to save data/code:

do http://www.radyakin.org/statalist/statabugs/label_crash_bug/bug_2019-08-19.do

Checked in Stata 14.0, 15.1, 16.0 for Windows. (Various Windows versions)

The command itself is not supposed to be executed this way, yet, I believe, the result should not be a crash that is observed.


In Windows 7 / Stata 14 the crash report is presented as shown below, in Windows 10 and Server Stata closes completely silently:




See also crash report message in plain text.

[Alan Riley (StataCorp)]

The following example demonstrates a sequence of commands that when executed crash Stata without possibility to save data/code:

do http://www.radyakin.org/statalist/statabugs/label_crash_bug/bug_2019-08-19.do

Checked in Stata 14.0, 15.1, 16.0 for Windows. (Various Windows versions)

The command itself is not supposed to be executed this way, yet, I believe, the result should not be a crash that is observed.
...

Here is Sergiy's do-file:

 // bug demo 2019-08-19 Sergiy Radyakin

clear all
input x
1
2
3
end

label define x 1 "a" 2 "b"
label values x x
mata
   v=J(0,0,.)
   st_vlload("x",v,v)
end

// end of file

The issue is the call in the do-file to the Mata function st_vlload(). This function is supposed to load the numeric values and string labels associated with the value label named in the first argument into the vectors in its second and third arguments.

The problem is that in this do-file, it is called with the identical matrix for the second and third arguments. Mata is first trying to make v a numeric vector, and then it tries to make it a string vector. It can't be both, and you can't store numeric values into a string vector or string values into a numeric vector, which leads to the crash.

Of course, it shouldn't crash -- instead it should check that arguments 2 and 3 to st_vlload() are not identical and issue an error message. We will fix this in a future update.

[Sergiy Radyakin]

Dear Alan,

thank you very much for following up on the bug report. This was purely an accidental find, and it was obvious from the code that it was my mistake and the command not to be executed that way.

Best, Sergiy