Could not step over: TypeError: Cannot read property 'file' of undefined

[Lykkeberg]

Compiler: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release)
Host OS: macOS Cataline (10.15.3)
VSC: 1.43.1
J-Link: 6.65b (other version tried as well)
Target CPU: Dialog DA14585
cortex-debug: v0.3.5

First of all: thanks a million for this great plug-in!

Got this error while single stepping a C code project with-in a static function. It works fine outside the static functions.

The specific function in this case, which can not be single-stepped is

static void setup_bme680(void)

I have included the .out file here for your help:

bme680-driver-design_585.out.zip

I have compiled with -O0 and -g3.

My launch.json file looks like this:

launch.json.zip

When I use the Debug terminal and enter i/n commands, single stepping works just like a charm, just not in the VSC UI.

[haneefdm]

Could you add "showDevDebugOutput": true to your launch.json and attach the output from the Debug Console?

Output from JLinkGDBServer (Output Tab, Adapter Output) can also be helpful

[Lykkeberg]

I have just tried to set the showDevDebugOutput to true and run the example again. I have put a breakpoint at the mentioned function. I then tried to single step 3 times, but no luck. The debug output is attached to this message.
debug-log.txt
Added output from adapter:
adapter-output.txt

[Lykkeberg]

Just tested again using the n and s commands in the Debug Terminal. It still works like a charm. I just noticed that the commands send to the debugger is somewhat different.

Using the step button:

0000075313: 69-stack-info-frame --thread 1 --frame 0
0000075314: GDB -> App: {"token":69,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[["frame",[["level","0"],["addr","0x07fca7ea"],["func","setup_bme680"],["file","./src/bme680_test_app.c"],["fullname","/Users/tly/Documents/Projects/Software/bme680-driver-design/src/bme680_test_app.c"],["line","110"]]]]}}

Using the n command:

n
0000235103: 70-thread-select 1
0000235103: 71-stack-select-frame 0
0000235103: 72-interpreter-exec console "n"
0000235104: GDB -> App: {"token":70,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[["new-thread-id","1"],["frame",[["level","0"],["addr","0x07fca7ea"],["func","setup_bme680"],["args",[]],["file","./src/bme680_test_app.c"],["fullname","/Users/tly/Documents/Projects/Software/bme680-driver-design/src/bme680_test_app.c"],["line","110"]]]]}}
...
...

Perhaps this can be of some help?

[haneefdm]

The debug-log.txt is incomplete I think. I see no next instruction to gdb. There should be something like -exec-next-instruction or exec-next or -exec-step-instruction or exec-step. If it is working manually from the REPL window, then that is strange indeed.

[Lykkeberg]

Yes, thats is correct. If I look into the gdb.ts and mi2.ts files, then it looks like there is some kind of parsing error which leads to the exception in line 1852 of gdb.ts, which tries to reference the 'file' attribute of the frame object. This fails for some reason. The frame object might also be 'udefined'. I'm not very much into the inner-stuff of these VSC plug-ins, but I'm very keen on getting to debug the plug-in. Do you know of a method on how to do that?

[haneefdm]

Thanks so much. My gdb.ts has moved on in my fork.

You are talking about this line right?

The file attribute being undefined or null or "" is fine because that is what checkFileExists checks for. It appears we could not get the frame itself. Now, that is weird. before executing that line, what is the value of the variable 'frame'? And what does the Debug Console look like at that point? I would single step from that point to see where it fails -- also put a breakpoint in the catch section.

From your debug log, it appears getting the frame actually succeeded and, it does have a file attribute.

Using the step button:
0000075313: 69-stack-info-frame --thread 1 --frame 0
0000075314: GDB -> App: {"token":69,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[["frame",[["level","0"],["addr","0x07fca7ea"],["func","setup_bme680"],["file","./src/bme680_test_app.c"],["fullname","/Users/tly/Documents/Projects/Software/bme680-driver-design/src/bme680_test_app.c"],["line","110"]]]]}}

[haneefdm]

Could you tell me the exact version of gdb you are using? I see you are using gcc-arm-none-eabi-7-2018-q2-update but not sure what actual version of gdb that is. I am using

HaneefMac-2018:Hello_World_2 hdm$ arm-none-eabi-gdb --version
GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[haneefdm]

One other trick. If I am having issues, just before I use an action, I clear the debug console, make that action (in your case click on the button) and see what comes out. Reduces the amount of info to look at, but not always the right thing because the problem may have started a bit before

[Lykkeberg]

I'm very keen on getting to debug the actual cortex-debug extension. But I'm a total NOOB on this. I tried to find some examples on the internet, but until now I had no luck. I would very much like to help getting this extension to its maximum, since I think it is super and a crucial tool in general Arm embedded software development.

Can you somehow, either walk me thru it, or point me in the right direction? Any help on this would be very much appreciated.

[Lykkeberg]

I have just dumped the GDB version information:

GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".```

[haneefdm]

Steps

• git clone the cortex-debug repo and run npm install in that dir
• Load cortex-debug source code into VSCode
• Use command-palette to run the task 'npm watch', wait a few seconds for code to compile
• set your breakpoints
• Start debug with "Extension + Debug Server" -- this starts a new VSCode window, load your project
  • Add, "debugServer": 4711 to launch.json of the embedded project
  • Try to reproduce the bug

Remember to remove the debugServer line after you are done

[Lykkeberg]

Hmmm, got the extension debugging environment up and running. But now the issue is not there. Wierd. But perhaps the extension runs in a different "mode"?

[haneefdm]

The whole thing did not make sense to me. Yesterday, I started suspecting a corrupt download/extension. Could you try un-installing the extension and re-installing it?

I would even nuke the direcotries ~/.vscode/extensions/marus25.cortex-debug* before a re-install.

[Lykkeberg]

I just did now. Nuking the extension directory and restarting VS code several times in between. Still the same problem. It is really weird and it only happens with static methods.

What if I tried to build and install the extension locally from the Github clone?

If so, can you advise on instructions on how to do it?

[haneefdm]

Yes, the runtime environment is a bit different. Before you do that, could you try the following? Download the following VSIX file...

https://github.com/haneefdm/cortex-debug/releases/tag/v0.3.6-pre1

See if that works. You download the file and use the Command Palette to load VSIX file manually

[Lykkeberg]

Just did. Same problem. "The plot thinkens".

I just did a small comparison of the Debug output from when I'm running in a clean release environment (the one failing) and in the extension debugging environment. I have just included them here. I can not see anything which stands out - at least not with my knowledge.
debug-log-working.txt
debug-log-not-working.txt

[haneefdm]

Do you have another computer you can try this on?

[Lykkeberg]

Yes, but this would take some time - not today. But I can have it running on monday afternoon (tomorrow).

I would like to try to compile and install the extension locally, can I do that and how?

[haneefdm]

I will take a look at the files you attached, maybe later tonight (few hours)

Steps. From memory. You have to install the vsce package (I think globally) and then package it which creates a vsix file. I forget the exact syntax. But, once you have a VSIX file, then you can install it manually

• run npm install -g vsce
• run vsce package

[Lykkeberg]

One last note. I just tried to install the extension from a local build - same problem. But with one extra little curly. There was two extra errors. I have attached an image to show that.

[haneefdm]

Yes, my pre-release is to address this issue. Last week, VSCode broke how hover works in an editor and asking for total junk to be evaluated. My pre-release mitigates that somewhat.

Keep your mouse away from the editor while you are trying to figure out what is going on.

[haneefdm]

I don't think you are using the latest source. I don't see the timestamps in the log files you attached.

[Lykkeberg]

I have removed the time stamps to be able to do a meaningful file compare - sorry for the inconvenience.

Thanks for the good afvises. I will try to debug further and also try on another computer.

I am having an idea of adding some debug output to the code (extension code), but I’m a bit confused as to how to do that when running in the release environment. Can you point me a direction of some ‘printf-like’ mechanism in the TypeScript system?

[stalyatech]

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git
VSC 1.43.1
JLink: 6.64b
Target CPU: STM32F745VG
cortex-debug: v0.3.5 (v0.3.6-pre1 also has been tried)

First of all: This is great extension to make easier everything. Thank you!

Unfortunately I have the same problem. I also test the v0.3.6-pre release to make sure. And I tried the GCC/GDB v6 and v7.

[haneefdm]

I have a NUCLEO-F429ZI board, wonder if anyone can help me duplicate the problem.

[stalyatech]

According to your directions, I did some debug and it seems some static functions have not been loaded to the "staticFuncs" list of the symbols.ts. I am nor sure why. Maybe the proejct size can effect the result.

[haneefdm]

@stalyatech Hmmm, but Cortex-Debug can work without even knowing any symbols or even source code. Also, to do a step or next we, don't even need the symbols. Sure you will not see good variables/watch windows but... function symbols (global or static) are only needed for disassembly.

Could you share your executable (elf file) so I can see what is going on? In case there is some other issue

[stalyatech]

Ok. the problem is symbol loader fills the lists (allSymbols and staticFuncs) with filename without the sub directory.

But "getFunctionByName" search the symbol list with sub directory. so it doesn't find the symbol (the function name that next code will be executed) in the list.

I am not expert of the ts. I just made simple touch to the "getFunctionByName" code such as:

public getFunctionByName(name: string, file?: string): SymbolInformation {
    if (file) {      // Try to find static function first
        file = file.split('/').pop();
        for (const s of this.staticFuncs) {     // Try exact matches first (maybe not needed)

After that everything seems perfect :)

[haneefdm]

@stalyatech You are more than likely on to something. But is not the right solution. You can have multiple files have the same base name with the same function/file names. Happens in auto-generated files and libraries

Thanks for your help. I wish I could have an executable or even the output of objdump. I think @Lykkeberg attached one, that I will have to dig through. I created many static functions and I could not duplicate this.

There are two problems here that I need to dig into. First, I have to have a proper elf file.

Thank you all, I will check back after a few hours of sleep.

[stalyatech]

@haneefdm thanks for your working again.

I attached the my elf file. maybe it can help you for digging.

firmware.elf.zip

[stalyatech]

@haneefdm the problem is
["func","sty_uart_init_helper"] is in the list.
["file","mods/machine_uart.c"] is not in the list. because the list contain the "machine_uart.c" as you see at the objdump file.

[Lykkeberg]

And, you all are seeing this problem while in a disassembly window? As in the active editor was a disassembly window?

No, in this case I see another issue. The singlestepping feature does not show the .cdasm file, but rather the .cdasm file from the calling module. The stepping feature works though.

[haneefdm]

Minor update. The output of objdump is so huge, that it is getting truncated by Node.js, so many path-names, symbols are not even seen/parsed.

Working on it.

[haneefdm]

I need some help. I will really appreciate the help.

I may have something that you @Lykkeberg @stalyatech could try. Looks like you can run from my fork repo source without me having to make a release. I can clean up and commit soon and let you know when ready.

@stalyatech your executable is ginormous. It takes 2.4 seconds to get symbols info from it. It overflows the Node.js buffers as well. I have a super-fast laptop. We are tied to Javascript so, not built for performance. I am experimenting with a caching mechanism.

[Lykkeberg]

I'm ready to help out - just say the word :-)

[haneefdm]

Fingers crossed. https://github.com/haneefdm/cortex-debug

[stalyatech]

I'm ready to test :)

[Lykkeberg]

Great news. I just tested with the exact same piece of code, and the exact same piece of HW, and the exact same breakpoint and single stepping operations.

It works like a charm. I can now single step and step-into functions, both static and non-static.

Great job :-)

I will spend the rest of my day, working on a project which needs this cortex-debug. I will report back this evening then.

[stalyatech]

Great job :-) @haneefdm
Everything looks good. As @Lykkeberg, I will let you know the any issues about the cortex-debug.

It is a perfect tool :)

[haneefdm]

Thanks, guys. Could you also make sure static variables are also being displayed properly?

[Lykkeberg]

Hi @haneefdm

First:
I must say, this is by far the best VSC extension in my portfoliio. Without it, I would not have been able to do my work without being forced to use the expensive compiler and debugging suites out there. Thank you guys for this marvellous work. I would like to chip in, if you can use my help.

Second:
I have been using your 0.3.6-pre2 build for a day now. Debugging, singlestepping, both static and no static methods. Inspecting static variables and other stuff. It all works like a charm. Sometimes these errors pops up, but I think they are unrelated to this issue.

They both happen when I'm setting breakpoints when the target is running. The break points are set though, but these errors pop up.

[haneefdm]

Thanks. Hmmm. Something changed in VSCode recently. I will look into it. I think setting breakpoints requires us to pause, set bkpt and then continue. The pause, however, causes all kinds of activity. All windows try to update themselves but by that time, the program is running again. Not all windows are controlled by Cortex-Debug but the registers window is. It is harmless though but should be avoided if at all possible

[haneefdm]

I am making some performance improvements for loading symbols. Again, has to do with statics. It is far too slow for my taste. Hopefully, when I am done, you can help me test the stuff again.

[Lykkeberg]

Great job. Yes, I will most certainly help you debug and test it again - you just say when :-)

[haneefdm]

Okay, we are ready for the next test round. I pushed everything to https://github.com/haneefdm/cortex-debug

Things to expect

• Hopefully, all the static stuff still works (most important)
• You should see a ~40% improvement in startup time reading symbols (compared t 0.3.6-pre1 or 0.3.5). But, if the executable doesn't change, then it should be mere milliseconds. It only matters for large executables. It went from multiple seconds to ~30ms
• You will see this in the timestamps in the 'Debug Console' if you have debug output enabled
• To remove cached results just do a touch on your executable to update its modification time

Cached results are stored in your systems TMP dir and each OS has different policies on how they purge so, once in a while (after reboot or X days after created). But, one time hit even if purged.

Thank you in advance. I hope you are doing well with the pandemic. Be safe

[Yocairo]

@haneefdm I am facing the same problem, and I tried out the fix as well. It definitely fixes the problem when stepping during debug. Thanks for the active support!

The only issue that remains for me is the following error message popping up:
Could not expand variable: Target is executing. (from stack-list-variables --thread 1 --frame 0 --simple-values)

However, this is not a blocking issue and seems to be ignorable for now.

[stalyatech]

@haneefdm everything seems great. Stepping in static functions, evaluating the static variables, huge symbol file loading are working just like a charm :)

Thank you for great job

I hope everyone are doing well with the pandemic

[Lykkeberg]

Hi @haneefdm. I have now been using the 0.3.6-pre3 build for a day now. It certainly load the elf files much faster - yay. No problems until now. This is looking very promising.

And again - thanks a million for all the nice work.

The Covid-19 is pulling some teeth now, since I have been working from home almost 3 weeks now. I hope that you all are well.

[haneefdm]

You are all awesome. Wish you well. One more round of changes and looking into the popups that @Lykkeberg mentioned. Other popups too. They are non-invasive but should not be happening. Ideally.

[haneefdm]

@Yocairo Could you describe the steps to reproduce this popup you are seeing? What was going on when you saw that popup? Also, your launch.json would be helpful

The only issue that remains for me is the following error message popping up:
Could not expand variable: Target is executing. (from stack-list-variables --thread 1 --frame 0 --simple-values)

However, this is not a blocking issue and seems to be ignorable for now.

[Yocairo]

@haneefdm Sure, I am just debugging as normal. It seems to only occur when I'm quickly stepping through code (spamming the step over key).

launch.json:
{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "debugServer": 4711, "name": "Debug (OpenOCD)", "type": "cortex-debug", "request": "launch", "servertype": "openocd", "cwd": "${workspaceRoot}", "executable": "exe/main.elf", "device": "STM32F427ZI", "configFiles": [ "scripts/stm32f4discovery.cfg" ] } ] }

Note: the debugServer entry was to use the source extension you provided above.

[haneefdm]

Thanks. I was able to duplicate. Problem is that whenever the debugger pauses the program (due to step, breakpoint, etc.) all windows try to update themselves. The problem is some requests are coming when the debugger had already started running again and not all windows have finished updating. The solution is not elegant but I will try.

[haneefdm]

I just pushed out 0.3.6.pre4 on my fork. https://github.com/haneefdm/cortex-debug.git

• I tried to suppress as many popups as I could for setting bkpts while running, banging on the step/next buttons, etc. All of them were harmless but a bit annoying.
• Changed static and global functions lookup from arrays (linear search) to maps. Tiny performance improvement but more importantly, cleaner code. May notice on very large executables.

The second change above means that static functions single-stepping could be affected. No change for static variables which were already cached.

[haneefdm]

Just made a PR #267 all the changes are in there. Hope to make a release soon.

[haneefdm]

0.3.6 is released. Thank you all. Please re-open if needed