I hope this question is appropriate here, since this is a problem when compiling my uBITx code.
Conflicted extensions with IntelliSense service were detected (Arduino). Code-completion, linting and navigation will not work properly. Please disable or uninstall them (Menu > View > Extensions).
I ignore this and (other than the occasional segmentation fault), everything still seems to work.
PlatformIO Extension: 2.10
Arduino Extension: 0.3.2
I know there are newer versions of Arduino available, but there the serial monitor in VSCode doesn't work with them.
Any ideas, 73,
Mark,toggle quoted messageShow quoted text
Very weird that GCC reports a segmentation fault, but only sometimes.
My best guess would be memory errors in the host computer.
Any chance you could try this on a different computer?
For somebody keen to hack hardware, a suitable host might be a Raspberry Pi 4.
Quite cheap if you already have a keyboard, mouse, and your TV has an HDMI port.
Or perhaps a borrowed laptop.
On Tue, Nov 10, 2020 at 06:35 PM, Mark Erbaugh wrote:
I'm using VSCode to do my Arduino coding. It took some setting up, but it is working well most of the time. Every once in a while, when I make a change to the code and compile it, GCC is reporting a segmentation fault. If I exit and restart VSCode, the next compile goes fine.
I've seen issues with the AVR compiler before. I've also used newer versions of the arduino IDE with VSCode. I don't think I've seen that lint warning, though.
I suspect the tool is confusing itself somehow, especially if a recompile fixes it. While a little annoying, unless you want to figure out and help fix the compiler bug, I'd say just recompile and move on :P
toggle quoted messageShow quoted text
That "segmentation fault" would seem to be happening in your computer
or in the Visual Studio software you are using to compile code for your
Arduino. This seems unusual because we usually see segmentation faults
in code that has been compiled and then run on some other target computer.
If I read this correctly your segmentation fault is happening in the computer
you are using to edit and compile code for use on an Arduino.
Segmentation faults are usually caused by jump or write statements that
try to access memory inappropriately, or try to write to memory that is
not accessible to the program being run. It can be caused by memory
faults, code errors, or CPU problems.
This problem may be hard to locate and maybe even more difficult to fix.
Core dumps may indicate where the fault is happening, but the segment
fault may destroy any footprints left behind by its action, depending on
where it tried to go and what it tried to do there.
This reference may give some insight into the problem, but it appears that
Visual Studio may have been written in Python, so the problem could also
be in the Python interpreter. Check that your version of PY code is
compatible with the release version of Visual Studio that you have installed.
There are other on-line discussions that appear to address segmentation
faults with Visual Studio.
Most of us are using the Arduino IDE for our work with AVR & Arduino systems.
The Arduino IDE shown in some Linux repositories shows as version 2.x when
in fact it is actually release 1.0 or earlier. This is because of a disagreement
between the IDE builders and the Linux community. If you are going to use the
latest Arduino IDE on Linux you really need to go to the Arduino IDE web sight
and download and install release 1.8.x directly from there.
On Tue, Nov 10, 2020 at 7:35 PM Mark Erbaugh <mark.election@...> wrote:
I did some research and found that the segmentation fault is related to an issue in newer versions of the AVR Board Manager in the Arduino program. The recommendation was to revert to version 1.6.21. I did that, and in dozens of compiles, I've not had a segmentation fault.
However, compiling the exact same source code results in greater memory usage. For example with a current project:
1.8.3 (newest) 29084 bytes of program and 914 bytes of variables
1.6.21 29346 bytes of program and 877 bytes of variables (262 bytes more program, 37 less bytes variables).
Again, this was exactly the same source code, I just changed the version of the AVR board manager.