[wingide-users] Re: Cannot execute: waiting for shell to restart. Ubuntu Jaunty - RESOLVED

[Doug Hawkins]

Hi Stephan,

I was able to make both versions (3.1.8 & 3.2.0b) work.  The problem is 
that the Ubuntu Jaunty upgrade left my loopback device (lo) 
unconfigured, so there was no route to 127.0.0.1 -- that affected 
several other programs in catastrophic ways, so it didn't take too long 
to sort out.

I wanted to let everyone know, in case they encounter the same problem.

Thanks,
Doug

Wingware Support wrote:
> Doug Hawkins wrote:
>> I saw this thread from Feb 09 (it appeared to be restricted to Vista 
>> x64), but did not find a resolution.  I've had no problems until I 
>> upgraded from Ubuntu 8.10 to 9.04 (32-bit) over the weekend.  Of 
>> course, that means lots of new packages and a new Linux kernel, but 
>> one specific difference: the system "default" is Python 2.6 (although 
>> Python 2.5 is still installed).  I've tried forcing the Project to 
>> use 2.5, but no difference.  Starting either Python from an external 
>> shell is fine.
>>
>> I tried Stephan's suggestion of enabling the Debug logging (and the 
>> Extremely Verbose option) and "Step into..." a program, but it did 
>> not create a log file.
>>
>> The error message I get is: "Failed to start the debug the program:  
>> Could not listen on TCP/IP host 127.0.0.1, port 0."
>>
>> I suspect that it has something to do with the "port 0", but my 
>> Debugger/"External/Remote" lists the server port as 50005.  Is this 
>> port configure elsewhere?
>
> No, that's the preference that should control this.  I wonder if
> there are new security features that prevent Wing from listening
> on this port?
>
> Maybe apparmor or ufw are doing something weird, tho I am just
> guessing at this point.
>
> I don't think a resolution was found for the x64 Vista issue,
> although we suspected some pre-installed 3rd party anti-virus
> software.  It could also have been the user had a debug version
> of Python.  We had accidentally omitted debugger support for
> _d versions of x64 Python in our Windows installer.  In any
> case, your issue is probably not caused by the same thing.
>