Remote Debugger Issue

One of the changes in Real Studio 2012 Release 2 was an improved Remote Debugger Stub.  It compresses the files it’s going to transfer which results in a significantly faster transfer to the remote machine.

I’ve been happy with it until today when I kept getting this error when trying Remote Debug into Windows in VMWare on my machine.

VMware FusionScreenSnapz001

 

Not a very helpful error message.  This occurred as soon as the first data packet reached the Debugger Stub.

After banging my head of against the wall for about an hour (and starting to panic a bit because of a deadline) I started poking around.  The stub has worked for me, without issue, for years.  Why now?  What changed?  I tried using an older stub, older IDE versions, and all sorts of things.  Since I had the older one, newest one, and even a new beta version I had renamed the folders so I could keep them in one folder.  Last week I consolidated and moved folders around so I could manage them batter.

Have you guessed what the problem is yet?  I finally went to options and that’s where I discovered that the Download Location I was putting the files into no longer existed.  A simple change fixed the error and I was able to use the Remote Debugger in Windows again.

Feedback report <feedback://showreport?report_id=23508> was submitted.  Ideally the Stub should check the location before a debugging session starts or if the location doesn’t exists uses a temporary location.  I suspect this one will get fixed rather soon.

So, there you go.  If you’ve been banging your head up against a wall trying to get Remote Debugging to work, you might want to check the Options/Preferences and see if the Download Location exists.  Hopefully this saves someone, somewhere along way, some time.  Happy Coding!

5 thoughts on “Remote Debugger Issue

  1. this sounds very familiar – i even found the very same Feedback with quite a low id:
    so either this issue dates back to 2008, or it has been fixed – and broken again some time later 😉

  2. I have a feeling that the internal real software coding culture is to program offensively rather than defensively.

    If I am correct, perhaps it’s because they understand that this allows the compiler to ultimately makes smaller tighter code. Who knows. Over the years, these nil object exceptions have been Evident in there build versions

    In our team projects, we test for nil all the time. Every where. Every time.

    It’s a very defensive programming style. We expect every call to fail and we do not rely on the framework to handle stack traces in the case of exception errors

    Our philosophy is be prepared for the worst and check for nil objects.

    Of course I’m only speculating because its fun

    I really like your blog Bob

Comments are closed.