First off, let me congratulate Wavecom on their new incredibly bad M2M Studio. Never before in my life have i worked with such a bad software. We now have to use twice as much time on software development as we did before because of this bug-filled piece of crap software.
Got to let that out… And now to the problem:
Each and everytime i step in debug i get a dialog saying that multiple errors occured which then states that
If i click Details it says
Thank you for your constructive comments…
We surely prefer knowing what points are making you so frustrated, rather than just hearing “it’s so bad”…
We can understand frustration, but we can’t do anything without a concrete list of points to be enhanced.
Concerning all the Target Management aspect, we are aware that it is not as stable as expected, and we are working on a deep refactoring we are going to publish in 1.2.0 release, available in beta state near the middle of April.
Now concerning the “Label Job” bug, we have just detected it a couple of days ago. It occurs in 1.1.1, when you attempt to perform step by step debugging in RTE mode. This is due to a regression in CDT (the Eclipse’s component dealing with C/C++), and is fixed in the following CDT release.
We are currently preparing an 1.1.2 release, just to fix this issue, by integrating the new CDT release (without changing anything else). This should be available at the beginning of next week; you should be warned of the release availability through the automatic updates.
(Please note that this bug doesn’t occur if you install M2M Studio 1.1.1 plug-ins over an Eclipse 3.5.1 platform).
where can i apply for the beta?
The beta will be publicly available, and download links will be published here on the forum.
More information on the “Label Job” bug:
We actually found that it is a random bug, and integrating a new CDT release isn’t enough to fix it, so finally we won’t release a 1.1.2 version. But the good news are that we have a workaround to fix the issue when it occurs.
When the “Labe job” bug occurs, please go to the C/C++ General > Indexer property page; you should have something like this:
To fix the issue, you have to restore the expected properties values, as it is normally set when the project creation is correct:
After that, the issue is fixed and the project can be debugged in RTE.
As far as I can see, the bug is not random, it’s caused when there is a missmatch between the build configuration used by the indexer, the active build configuration, and the current action.
For example, if the indexer is configured to use the active configuration, you can reproduce the bug by doing the following:
Now, when execution hits the break point you will get the label error. If you set the active build configuration to the RTE target, debugging works as expected.
While it may appear to be random if you weren’t aware that the target you are debugging was not the last one you built, at least for me, this is consistently the cause of this bug. Maybe other people really are having random problems with this bug, but I suspect this is the culpret.
The obvious workaround is to tell the indexer to always use the RTE debug target. The problem here is that when working with another target, the indexer becomes worse than useless, as it is indexing the wrong build.
Given that if you try to debug a target that is not the active build configuration, it is automatically rebuilt, the UI obviously considers this a valid action, so should therefore know to update the indexer too.
Thank you very much for your analysis, I think you’re not far from the truth. The random factor seems linked to the fact that Indexer settings are not always persisted correctly (i.e. you save them to a given value, close/reopen M2M Studio, and then they are set to another value…).
However, that’s giving us clues to fix the “issue” (or workaround CDT behavior is not possible to fix).
That might be true. But then i could use 3 full work days just to write all the bugs and “features” that just don’t work in M2M Studio. You have to remember, we pay for our Wavecom hardware and as such, expect a working development studio, which we had back when you supported Visual Studio.
Still constructive, as I see 
Now you have two options:
