Arduino IDE issues

Well, it has been a long time since I blogged anything so I thought I would jot down some notes about my experiences of late using recent builds of the Arduino IDE.

I have over the last couple of years been working almost exclusively on Linux workstations, specifically Ubuntu 16.04 LTS and later and my comments are based on my experience on that platform.  I have not yet attempted to reproduce any of this on Windows though I have no reason to doubt that experience would be the same.

In my case, I have loaded up Arduino 1.8.1 on Linux and I have several comments about the later builds and this one in particular.

1. There has been a lot of work done on board management and library management and this from my perspective has been a very worthwhile addition to the system.  Having the ability to be notified when updates have been produced to the set of development boards supported as well as the libraries is a huge improvement over the older experience.  Trying to make sure you get a library zip file loaded in exactly the correct folder without destroying the base install is a welcome addition.
2. In the same vein, there has been a bit of expansion on the scope of the 8 and 32 bit processors supported.  This support is bundled up in packages that can be individually installed to add or remove support.
3. Someone finally addressed the issue of the serial monitor and serial plotter output windows having to be closed in order to recompile and upload the code.  Thank you!

There has also been a lot of work in turning on (by default) the various code optimization flags for the compilers and this has resulted in a lot of code space savings for my projects and I know for others.  It has not come without a price however and this is one of the things I want to highlight here.

One thing I have noticed is that the "link-time optimization" flags have been added to the default options during compile and link.  If you enable verbose output in file->preferences dialogue shown below, you can see these additional command line options during compilation.

While I am a fan of compact code, enabling these options on one of my projects has resulted in the code linker seg faulting during compilation.  I have not yet created a simple repro of the issue.  The following code illustrates the issue, but does not fail to compile, so my understanding of the issue is as yet incomplete.  I wrote this to try and reproduce the issue, but it fails to fail...


class data
{
public:
    int a;
    int b;
};

class classB
{
public:
    void doSomething(data *pData);        
};

class classA
{
public:
    void doit();
    
private:
    classB b;
    data d;   
};

void classB::doSomething(data *pData)
{
    pData->a = 1;
    pData->b = 2;
}

void classA::doit()
{
    b.doSomething(&d);
}


classA *pA;

void setup()
{
  pA = new classA();
}

void loop() 
{
    pA->doit();

}

The basic idea is that I have a class (classA) that has two other classes embedded in it (classB and data).  ClassB has a method (doSomething) that gets passed a pointer to class data which it attempts to use to access public variables in class data.  In my failure case, if I comment out the call to b.doSomething(&d) everything compiles fine.  If I uncomment it, the GNU linker Segment Faults and terminates.  The code above does not reproduce the symptoms.  In my project that does reproduce the problem, if I remove the -flto command line option to disable the link-time optimizer, there is no crash and with the option set it does crash.

There is a lot of discussion on the GNU tools blogs about this problem though my repo seems to be somewhat unique, so I have not been able to narrow the problem down further.  https://github.com/arduino/Arduino/issues/660

My temporary solution is to disable the link time optimizer and finish up the project.  Once it is complete, I will re-enable the option and see if the problem still reproduces.  I am not quite ready to publish this project, so I am going to wait until it is finished before reporting a bug back to GNU as I will have to publish the code to them to get it investigated.  Otherwise, I will build the tool myself from the source and debug it myself.  I just don't want to take the time at this moment with a side trip into debugging my toolchain.

Mostly, I wanted to publish this so that readers will be aware of it and if anyone has encountered the same problem, I would love to compare notes.