[daniel klein]

Thanks for posting (part of) the trace. Unfortunately, it is still unclear from that trace, which program generated the error. Please show the trace -- verbatim -- of

set tracedepth 32000
set traceexpand on
set tracesep on
set traceindent off
set tracenumber on
set trace on
[i]whatever_your_command_call[/i9

starting about 10 lines above the error message all the way to the return code r(111); including all separator lines. Do this inside code-delimiters as I have done above.

[Mark Franklin]

It is hard to know how to do what you suggest and have it be of any use to you. The program that fails on exit (program B of my original post) has some 800 lines of code (as I mentioned earlier) and the final segment starts at the end of program C (actual name genstacksP) of some 600 lines, itself previously called by program B. I have done my best to produce something helpful by interrupting execution with an `exit' command, which (in this instance) does produce the infamous error message a little earlier in the trace output, before the merge shown in my previous example. This leaves me with a meaningful chunk of trace output with a tolerable number of lines not executed. Before that there are 372 lines of trace output that is not executed (by-passed by a failed 'while' condition) and which I therefore omit, enabling me to go all the way back to the `end' command (evidently not shown) of genstacksP. Here you are . . .

     ------------------------------------------------------ end genstacksP ---
    - tempfile i_`c'
    = tempfile i_1
    - quietly save `i_`c''
    = quietly save /var/folders/0q/bssdjp717kx6bsyycqlyc26c0000gn/T//S_09136.000003
    - if `c'==1 local temp = "`i_`c''"
    = if 1==1 local temp = "/var/folders/0q/bssdjp717kx6bsyycqlyc26c0000gn/T//S_09136.000003"
    - else {
      local appendtemp = "`appendtemp' `i_`c''"
      }
    - restore
    - }
    - local multivarlst = ""
    - local nvarlst = 0
    - }
    - gettoken prepipes postpipes : postpipes, parse("||")
    - if "`postpipes'"=="" local lastvarlst = 1
    = if ""=="" local lastvarlst = 1
    - if strpos("`prepipes'", ",")>0 {
    = if strpos("", ",")>0 {
      gettoken anything opts : prepipes, parse(",")
      }
    - else {
    - local anything = "`prepipes'"
    = local anything = ""
    - local opts = ""
    - }
    - if "`anything'"=="" {
    = if ""=="" {
    - local more = 0
    - }
    - }
    - while `more' {
    = while 0 {
--------------------------------------------------------------------------------------------------------------
 /* 372  LINES OF TRACE OUTPUT FOLLOWING ‘while’ WAS NOT EXECUTED /*
--------------------------------------------------------------------------------------------------------------
     }
    - if !`noMultiContxt' {    
    = if !1 {
      preserve                  // EXAMPLE OF CODE NOT EXECUTED
      quietly use `temp', clear
      local napp = wordcount("`appendtemp'")
      forvalues i = 1/`napp' { 
      local a = word("`appendtemp'",`i')
      quietly append using `a', nonotes nolabel
      erase `a'
      }
      quietly save `temp', replace
      restore
      }
    - capture exit             // INSERTED COMMAND REVEALS THE SAME ERROR AS AN (UNSEEN) 'end' COMMAND
display not found
r(111);

[Mark Franklin]

Of course this (already rather long) chunk of trace output does not tell you what happened in genstacksP, where the error might in principle originate. However, as I mentioned in an earlier post, I already established (by progressively moving the 'end' command closer to the beginning of the executed code – this took a couple of days) that program C (genstacksP) is not the source of the problem, which apparently is located somewhere in the first half of program B (named as in my original post). I am still trying to unpack the 400 or so lines involved into half-a-dozen separate programs, eventually to be called in sequence, which I hope will eventually narrow down the location of the offending statement to one of those subroutines. So far, after several hours of frustration, I have not yet managed to finish debugging even the second of these eventually six subroutines; so I really hope you can come up with a suggested diagnostic procedure that will be less labour-intensive. My worry is that, even after all that, the problem will turn out to be inherent in the program structure rather than in any specific Stata command.

[daniel klein]

I have never seen the retrun code immediately following the error message in a trace. It should at least look something like this:

. a
   ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- begin a ---
02 - b
display not found
   --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- end a ---
r(111);

Notice that there is a separator line after the error message and before the return code. With sufficient tracedepth, there are likely to be more separator lines.


Also, your trace now shows completely different commands than the previous one. Maybe this is because you followed my advice to

set tracedepth 32000

maybe it isn't; as you did apparently not follow my advice to

set tracenumber on

You have also not shown what you typed, exactly, to produce that trace.

All I can say is that, in a noncorrupted copy of Stata, neither

capture drop stkmiss

from your first trace nor

capture exit

from your second trace will produce the error message that you show. So the error must be somewhere else.

If what you show here is exactly what you see on your screen (EDIT: following my advice to set sufficient tracedepth), which I seriously doubt, then run

update all , force

Whether that helps or not, do show us what you typed, exactly, to produce the traces.

[Mark Franklin]

Sorry I failed to follow your instructions regarding tracing. Here is what I get when I follow them. I started by quitting Stata and re-invoking in, in case it had been corrupted. The new trace record seems exactly the same as before, except that macro expansion is off (except just once) despite having been explicitly turned on, nesting level is now shown, and the 372 lines of trace output recording non-executed code in my previous post are nicely omitted. I also now show what I typed . . .

genstacks RSYM RSYML RLRPP, context(rstudyid)

03 set tracedepth 32000
03 set traceexpand on
03 set tracesep on
03 set traceindent off
03 set tracenumber on
03 set trace on
03 tempfile i_`c'
03 quietly save `i_`c''
03 if `c'==1 local temp = "`i_`c''"
03 else {
03 local appendtemp = "`appendtemp' `i_`c''"
03 }
03 restore
03 }
03 local multivarlst = ""
03 local nvarlst = 0
03 }
03 gettoken prepipes postpipes : postpipes, parse("||")
03 if "`postpipes'"=="" local lastvarlst = 1
03 if strpos("`prepipes'", ",")>0 {
03 gettoken anything opts : prepipes, parse(",")
03 }
03 else {
03 local anything = "`prepipes'"
03 local opts = ""
03 }
03 if "`anything'"=="" {
03 local more = 0
03 }
03 }
03 - if !`noMultiContxt' {
= if !1 {
03 preserve
03 quietly use `temp', clear
03 local napp = wordcount("`appendtemp'")
03 forvalues i = 1/`napp' {
03 local a = word("`appendtemp'",`i')
03 quietly append using `a', nonotes nolabel
03 erase `a'
03 }
03 quietly save `temp', replace
03 restore
03 }
03 - capture exit
display not found
r(111);

Yes. The error must be somewhere else. Hence my attempts to localize it. And yes, I did terminate the program earlier than previously, in an attempt to get a more helpful code selection. Regarding the character of the error report, in 20 years of Stata programming I also have never seen an error message reported in this fashion. I had hoped it might provide a clue as to what was going on. Thank you for your help with this.

[Mark Franklin]

I forgot to say that I did try an 'update all, force', as you suggested. Another very good idea. Thanks. Evidently it made no difference, but that is one more possibility ruled out.

[Joseph Coveney]

. . . that is one more possibility ruled out.

Well, that error return code (111) is specifically for attempting to do something with a variable that doesn't exist by that name. You might have intended to call the command display, but somehow during the code-editing process, you inadvertently removed the carriage return-line feed before it and it ended up being appended to a varlist on the preceding line. Whatever, your code somewhere has a command that tries to call a variable named display.

At this point, your best bet might be to fire up your favorite text editor, open those ado-files or modules called in proximity to where the error arises, and have the text editor highlight all instances of <white space>display<white space>. Bracketing the search term by white spaces should eliminate legitimate calls to the display command, although you'll still have to manually ignore the word's presence comment fields.

As tedious as that might sound to you, you'll likely get there faster than by the path you're on now: we're up over twenty fruitless posts in this thread alone, and there are two threads on the list about your problem.

[daniel klein]

#20 explains a lot. You are using set trace commands inside programs. Don't!

Instead, remove all set trace commands from within all programs. Then, type in the command line:

set trace off
set tracedepth 32000
set traceexpand on
set tracesep on
set traceindent off
set tracenumber on
set trace on
genstacks RSYM RSYML RLRPP, context(rstudyid)

This will produce a (much) longer output; you may have to log. It will also separate the error message from the return code. Scroll through the output to find the error message (a simple text editor search will help). The line above the error message is the offending statement. The number printed at the beginning of that line is where the error occurs; more precisely #-1 levels of programs down from genstacks. The separator lines with the end programname statements will identify the offending program's name. If the output is overwhelmingly long, reduce the trace depth -- but keep it at least at # -- then re-run.


Edit / added (slightly off topic): I can tell that you are using set trace inside of programs because the set trace commands are part of the trace. Moreover, I can tell that these commands appear 2 levels down from wherever the trace has been set on before; yes the trace must have been set on elsewhere, perhaps from the command line, a do-file, or a previous run. Otherwise, we should not see any set trace commands as part of the trace, and the number should be 01 or 02 at most. Moreover, append is an ado-based command (although most of work is done internally). Hence, the number 03 should increase at that point of the trace, and we should get to look into what append is doing. Because 03 does not increase, the tracedepth has not been (re-)set deeper than 3. The respective line shown in the trace has obviously not had any effect; probably because a trace with different settings (also no separate lines) was already running at that point. As I have emphasized repeatedly, it is important to set tracedepth sufficiently deep to print the offending line of code. Please do follow my instructions exactly.

[Mark Franklin]

This is SO helpful. Thank you SO much. It is exactly what I was hoping for when posting to this list for the first time. I got none of this from the cursory reading of the 'set trace' help text (evidently I should have read it more carefully and more thoughtfully; but it is rather terse for the complexities you reveal. Again I thank you. It will be a few days before I try what you recommend because I am off on a three-day mini-vacation with my family. =Mark

[Mark Franklin]

MYSTERY SOLVED. As suggested by Daniel Klein in an early response to my original post, there was a local macro involved. It was in a calling program that was not being traced and did its damage after the called program encountered an 'end' command, returning execution to the buggy calling program.

So I was looking in the wrong place: before an 'end' statement instead of after. The error popped out as soon as I had comprehensive tracing in place, as suggested by Daniel in a later post.

I am SO GRATEFUL for the expertise that enabled me to solve this (to me) very obscure riddle. The offending statement is the last of the following 4, executed only in the absence of a specific user option. When the 'else' clause is true, the empty `w' leads to the statement 'if display as error ...' with the inevitable result that mystified me.

stackmeWrapper genstacks `0' \ prfxtyp(`prfxtyp') `multicntxt' `optMask' // Name of stackme cmd followed by rest of cmd-line
capture confirm variable `itemname'                                     // Code executed on return from 'stackmeWrapper
if !_rc  local stackMeLabel1st = "STKD_`itemname'"                     // Add '_itemname' to what will be 1st word of data label
else  if `w' display as error "WARNING: 'itemname' is not optioned, so battery items are identified by SMstkid{txt}"

Thank you again, Daniel, especially for your patience in face of my careless failures to do exactly what you asked.