[SailfishDevel] sporadic bouts of "Could not connect to MerSDK Virtual Machine. Timeout waiting for reply from server."

Christopher Lamb christopher.lamb at thurweb.ch
Thu May 29 16:29:22 UTC 2014


Hi All

I am still suffering from this issue, and getting more and more frustrated!

Right now "it" is refusing to deploy as RPM to the Emulator.

Is anything I can do to better debug / understand this issue?

The timeout settings previously suggested are probably red-herrings, as 
they apply to the device (phone / Emulator), whereas the error is a 
timeout to the SDK.

All help greatly appreciated.

Grüsse

Chris



On 28.04.14 08:01, christopher.lamb at thurweb.ch wrote:
> Hi
>
> Thanks.
>
> I found a well hidden {1} timeout setting in the preferences / devices 
> and increased this from the default 2 secs to 10 secs. This does seem 
> to help, but as always with sporadic problems only time will tell if 
> this is a fix, or if the problem is just dormant for a while.
>
> What I don't understand is, given the error says "Could not connect to
>>> MerSDK Virtual Machine" why should a timeout for connecting to a 
>>> Jolla device play any role?
>
> Is the error misleading? is the problem actually in connecting FROM 
> the MerSDK to the Jolla?
>
> Chris
>
> {1} when the preferences pane opens, at least on my OSX host the 
> timeout setting is "offscreen" in an embedded pane with scroll bars in 
> the middle of the preferences pane. Only if you scroll down in the 
> embedded pane are further settings including the timeout revealed. 
> Truly a wonderful bit of UI design 8-)
>
>
>
> Zitat von fasza2mobile at gmail.com:
>
>> I believe the  timeout setting can be adjusted in QtCreator where you 
>> set up your mer device(ssh password, etc). By increasing this value 
>> you can probably prevent the timeout issue altogether. I don't have 
>> the SDK in front of me to give you the exact menu you need to open, 
>> but it isn't too hard to find once you know what you're looking for.
>>
>> On Sat Apr 26 2014 13:41:20 GMT+0100 (BST), 
>> christopher.lamb at thurweb.ch wrote:
>>> Hi All
>>>
>>> I am suffering from sporadic bouts of the error: "Could not connect to
>>> MerSDK Virtual Machine. Timeout waiting for reply from server"
>>>
>>> One moment I can be happily hacking and deploying code to my Jolla
>>> without error. Then I make a small change to the code, try to deploy,
>>> and bing! the error rears its ugly head once again like a scandinavian
>>> troll from under a bridge.
>>>
>>>
>>> Project ERROR: Could not connect to MerSDK Virtual Machine. Timeout
>>> waiting for reply from server.
>>> 14:02:28: The process
>>> "/Users/christopherlamb/.config/SailfishAlpha4/mer-sdk-tools/MerSDK/SailfishOS-armv7hl/deploy" 
>>> exited with code
>>> 1.
>>> Error while building/deploying project landed26_QT5 (kit:
>>> MerSDK-SailfishOS-armv7hl)
>>> When executing step 'Rpm'
>>> 14:02:28: Elapsed time: 00:27.
>>>
>>>
>>> When the error occurs, there seem to be at least 2 variants:
>>>
>>> 1) It will successfully deploy "As binaries" without error, but will
>>> give the error on "deploy as RPM".
>>>
>>> 2) Any kind of deploy gives the error.
>>>
>>>
>>> The strange thing is, that despite the error, it does seem to
>>> (sometimes) deploy (or possibly partially deploy) code.
>>>
>>> Right now I am getting the error in constellation 1), so according to
>>> the error a "deploy as RPM" should fail. Yet the test below indicates
>>> that it is at least partially deploying code.
>>>
>>>
>>> [root at Jolla javascript]# pwd
>>> /usr/share/landed26_QT5/qml/javascript
>>> [root at Jolla javascript]#
>>> [root at Jolla javascript]# ls -ahl
>>> total 52K
>>> drwxr-xr-x 1 root root  180 2014-04-26 13:56 .
>>> drwxr-xr-x 1 root root  110 2014-04-26 13:56 ..
>>> -rw-r--r-- 1 root root 4.2K 2014-04-26 13:55 jsonpath.js
>>> -rw-r--r-- 1 root root 1.3K 2014-04-26 13:55 jsonSupport.js
>>> -rw-r--r-- 1 root root  349 2014-04-26 13:55 landed.js
>>> -rw-r--r-- 1 root root 1.2K 2014-04-26 13:55 message.js
>>> -rw-r--r-- 1 root root 8.4K 2014-04-26 13:55 readDataModel.js
>>> -rwxr-xr-x 1 root root 8.8K 2014-02-03 08:32 settingsDB.js
>>> -rw-r--r-- 1 root root 5.2K 2014-04-26 13:55 writeDataModel.js
>>>
>>> //create new file testDeploy.js in QtCreator, then attempt deploy as
>>> RPM. Error is generated. Repeat attempt to deploy as RPM. Error is
>>> generated again.
>>> //but testDeploy.js is now on the Jolla!
>>>
>>> [root at Jolla javascript]# ls -ahl
>>> total 56K
>>> drwxr-xr-x 1 root root  206 2014-04-26 14:01 .
>>> drwxr-xr-x 1 root root  110 2014-04-26 14:01 ..
>>> -rw-r--r-- 1 root root 4.2K 2014-04-26 14:00 jsonpath.js
>>> -rw-r--r-- 1 root root 1.3K 2014-04-26 14:00 jsonSupport.js
>>> -rw-r--r-- 1 root root  349 2014-04-26 14:00 landed.js
>>> -rw-r--r-- 1 root root 1.2K 2014-04-26 14:00 message.js
>>> -rw-r--r-- 1 root root 8.4K 2014-04-26 14:00 readDataModel.js
>>> -rwxr-xr-x 1 root root 8.8K 2014-02-03 08:32 settingsDB.js
>>> -rw-r--r-- 1 root root   38 2014-04-26 14:00 testDeploy.js
>>> -rw-r--r-- 1 root root 5.2K 2014-04-26 14:00 writeDataModel.js
>>>
>>> So it looks like that after a second failed deploy, the file is
>>> actually deployed!
>>>
>>>
>>> During bouts of the error, QtCreator seems to get out of sync the true
>>> status of the SDK VM (indicated by the VirtualBox GUI). So QtCreator
>>> may show the green "Start SDK" status, even though the SDK is already
>>> running. Or QtCreator shows the same button grey.
>>>
>>> So far I have not found any lasting solution to prevent the error in
>>> the first place. Sometimes it goes away on its own accord, and
>>> sometimes various combinations of restarting VirtualBox, the VM,
>>> QtCreator or my development host help for a while (but rarely for 
>>> long).
>>>
>>> What exactly is the timeout? Is this a property that I can increase?
>>>
>>> The "known issues" page of the Alpha (Qt4.8) SDK suggests:
>>>
>>> https://sailfishos.org/wiki/SDK_Alpha_Known_Issues
>>>
>>> VBoxManage modifyvm MerSDK --natdnshostresolver1 on
>>>
>>> But that has not helped.
>>>
>>> I am running the very latest version of the SailfishOS SDK, but had
>>> the same error with previous versions.
>>>
>>> Any ideas?
>>>
>>> Chris
>>>
>>>
>>>
>>> _______________________________________________
>>> SailfishOS.org Devel mailing list
>>>
>> _______________________________________________
>> SailfishOS.org Devel mailing list
>>
>
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list



More information about the Devel mailing list