Fixing VisualGDB issues – toolchain test failed.

[george.r.wicks]

Hi:

I am developing an application for the Raspberry Pi 4 using VS 2022 and VisualGDB.

When the VisualGDB is setup & functioning well, its great. But it’s a nightmare to deal with if you introduce anything out of step – I feel like I’m battling a barrage of VSGDB wizard problems. Case in point: I decided to add a new Raspberry Pi box (IP address 10.0.0.78) for development on a project that was working, which had a change for adding the pthreads library. It was working on the other Raspberry Pi box (IP address 10.0.0.59). I decided to use that same project BUT forgot to setup the new IP address in the project while adding the wiringPi library after the pthreads name. That resulted in a chain of events where I have ended up with “Toolchain test failed: The target system image does not match the elected toolchain: Command: lsb_release -c …”

I have seen other forum posts where some developed solved it by just re-doing the project. While that solved that person’s problem, its not a good solution in the long run.

There should be a better way to really help people resolve problems without completely re-doing the project.

Thanks,

George Wicks

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This type of error happens when users change multiple settings at the same time, forget what was changed, and end up selecting the settings that don’t make sense in their context. We suggest re-creating the project from scratch because it dramatically reduces the complexity of the whole setup – instead of checking every possible setting that could be causing the problem, you start from scratch, double-check that a handful of options selected in the wizard makes sense, and end up with a working project.

You can then compare that project against the broken one using a diffing tool (e.g. KDiff3) and quickly find out the mismatching setting.

The best way to avoid this type of problems is to change one setting at a time, verify that everything still works, and make frequent commits to your git repository, so that you can easily roll back to the last configuration that worked. We even have a separate page urging our users to follow this practice, but we still get a fair share of inquiries where the project is broken, the user is not sure what exactly they changed, and they are hoping that we can rescue a non-trivial project that we have never seen before.

Regarding this specific error, there isn’t much we can add to the error message: you somehow ended up with a toolchain that doesn’t match your SD card image. We don’t know what exactly you changed to get to this point, so we cannot point you to one specific setting that will undo it. If the newly created project works while this one doesn’t, please try comparing the .vgdbsettings/.vgdbcmake files between them – it should help you find the critical difference. If you can point to a specific XML element in the settings that is different, we can point you to the GUI setting that controls it, but it should be straight-forward in most cases.

[george.r.wicks]

I will do what you suggest, but I can tell you that re-doing things from scratch is precisely what I want to avoid

I can truthfully tell you that always putting the onus for unraveling the problems on the user is a sure fire way of insuring that developers will try to find an alternative to VisualGDB. And given that a good deal of the tutorials were written for previous versions of your toolset has already contributed to a lot of confusion and misunderstandings in your developer community. (there are several examples where the tools have changed significantly, and hence can lead to enormous confusion). And I’ve seen many posts that seem to indicate a reluctance on your part to re-do any of the tutorials.

Perhaps you have a strong customer base with a great deal of knowledge about VisualGDB – good! But right now, I know that I’m not exactly in that same boat, and I wonder how many others there are like me?

But thanks anyhow.

George

 

 

[george.r.wicks]

Also, please stop with the insinuation that developers are “making multiple changes to the settings”  – this is not the case, and you are definitely turning off customers with that kind of cavalier judgement. Not a good thing.

G

 

[support]

Hi,

We are sorry for the inconvenience and will try to explain the motivation behind our support limitations.

We have previously tried doing exactly as you suggested – spend as much time as possible to unravel such issues for our customers. It didn’t work at all. Whenever we helped them untangle everything, they would very quickly come back with another problem in a different project, then another one, with more to follow. The complexity and amount of these problems would grow exponentially to the point where we would not be able to unwind them anymore. They would then blame VisualGDB for being useless and leave extremely frustrated.

We spent a lot of time trying to figure out why some users are mostly happy with VisualGDB, while others continuously run into problems where virtually nothing works. We found one particular difference: the bug reports that we are able to reproduce are usually separated from the greater context (e.g. other libraries, projects created earlier, etc). They start from scratch and show that using some specific settings together results in something unexpected. We usually fix such issues very fast, or suggest reasonable workarounds.

The bug reports where we cannot do anything follow a different pattern: a complex setup involving non-trivial projects, typically no notes, no source control, and the users are not sure what exactly they did to trigger the problem. This could be very easily avoided by using source control and keeping detailed notes of any changes you do to the environment (e.g. install new libraries, synchronize sysroot, etc). If you do not have that, it is really easier to re-create everything from scratch. This is not specific to VisualGDB, these are generic best practices that would save you lots of time with any IDE or tool. If you still don’t believe us, you can do an experiment – ask a friend to change a few random settings in a complex project until it breaks, and measure how much time it would take you to find what was changed without having the change logs. It will take orders of magnitude more time to find the problem than it took to create it. While having notes and source control, where you can just take a few steps back, would make it almost instantaneous. Again, it’s not specific to VisualGDB – it comes from the general complexity of the setup involving multiple libraries, toolchains and frameworks.

As for VisualGDB alternatives, if you know any similarly priced product that would investigate customers’ projects without charging an hourly rate, we would be more than happy to analyze how they manage to achieve it, and try to offer something similar. We are not aware of anyone being able to do that though – asking for the repro steps is a standard practice when it comes to complex software that involves many components coming from different sources.

Regarding the tutorials, we usually update them when there are non-trivial changes to the GUI (prioritizing by the number of tutorial views). We do not update them for cosmetic changes of the GUI, and we do not update the tutorials that have relatively little views. If you can point out a specific tutorial that is confusing given the latest VisualGDB, and provide more details on what you find confusing, we will try to address it.

With turning off customers, we are merely trying to set realistic expectations. If you divide the VisualGDB maintenance price by 12 months, you get way less than an engineer’s hourly rate. This is possible because many common VisualGDB features work the same way for multiple users, so the effort took to develop them scales up. Project-specific support does not scale – it’s unique to each user. So the support that can be realistically offered at this price comes down to pointing out the relevant documentation (and often updating it based on popular requests), and troubleshooting issues that can be reproduced and fixed in reasonable time. We do absolutely offer the in-depth troubleshooting screen sharing sessions for quickly solving the toughest problems, however we do charge our consulting rate for it, as it’s not viable to offer it at less than $10/month.

[Author]

Posts