Blog/Parallels

From kJams Wiki
Jump to navigation Jump to search

summary

Parallels Desktop is awesome. Except when it's not.

And by "when it's not" I basically mean every %@#!$!@# time I'm debugging my app, and I "accidentally" hit "copy" or "paste" between the VM and the Host OS.

You see, Parallels has an extremely vexing bug causing it to HANG, when Visual Studio is pausing an app in the debugger, and you attempt to use the clipboard to move text between the VM and the Host.

I used to be able to work around this by just not using copy and paste, EVER, while debugging. But you can imagine this was VERY hard to train myself to remember to do, in fact, i forgot all the time, forcing me to force-quit parallels _A LOT_.

But now the problem is much worse. You see, in Mavericks, it apparently enjoys syncing the clipboard even when i'm not copy and pasting BETWEEN the host and guest. So if i ever pause in the debugger in parallels, it could, at any time, just freeze up. You can imagine this is becoming something i can no longer live with.

the call stack

Here's a call stack of the offending behavior:

Sampling process 22986 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling prl_client_app (pid 22986) every 1 millisecond
Process:         prl_client_app [22986]
Path:            /Applications/Parallels Desktop.app/Contents/MacOS/prl_client_app
Load Address:    0x100000000
Identifier:      com.parallels.desktop.console
Version:         9.0 (24172.951362)
Build Info:      Parallels-24172.951362~9.0.24172.951362
Code Type:       X86-64
Parent Process:  launchd [359]

Date/Time:       2014-02-20 22:06:53.499 -0800
OS Version:      Mac OS X 10.9.1 (13B42)
Report Version:  7

Call graph:
    2554 Thread_945225   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2554 start  (in prl_client_app) + 52  [0x10000db74]
    +   2554 ???  (in prl_client_app)  load address 0x100000000 + 0xa7c9f  [0x1000a7c9f]
    +     2554 QCoreApplication::exec()  (in QtCorePrl) + 188  [0x10645637c]
    +       2554 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)  (in QtCorePrl) + 324  [0x106453f44]
    +         2554 QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)  (in QtCorePrl) + 68  [0x106453b94]
    +           2554 QDesktopWidget::resizeEvent(QResizeEvent*)  (in QtGuiPrl) + 13040  [0x1066fba30]
    +             2554 -[NSApplication run]  (in AppKit) + 553  [0x7fff926ec9cc]
    +               2554 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]  (in AppKit) + 122  [0x7fff926f88db]
    +                 2554 _DPSNextEvent  (in AppKit) + 1434  [0x7fff926f928e]
    +                   2554 _BlockUntilNextEventMatchingListInModeWithFilter  (in HIToolbox) + 65  [0x7fff9938fabc]
    +                     2554 ReceiveNextEventCommon  (in HIToolbox) + 479  [0x7fff9938fcb7]
    +                       2554 RunCurrentEventLoopInMode  (in HIToolbox) + 226  [0x7fff9938ff0d]
    +                         2554 CFRunLoopRunSpecific  (in CoreFoundation) + 309  [0x7fff986be275]
    +                           2554 __CFRunLoopRun  (in CoreFoundation) + 1830  [0x7fff986bebd6]
    +                             2554 __CFRunLoopDoSource1  (in CoreFoundation) + 478  [0x7fff986cdade]
    +                               2554 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__  (in CoreFoundation) + 41  [0x7fff986cdb69]
    +                                 2554 __CFMessagePortPerform  (in CoreFoundation) + 760  [0x7fff98747f78]
    +                                   2554 __CFPasteboardClientCallBack  (in CoreFoundation) + 1054  [0x7fff98770d9e]
    +                                     2554 PasteboardCopyDataProc(void*, __CFPasteboard*, long, long, __CFString const*)  (in HIServices) + 550  [0x7fff97f2ef10]
    +                                       2554 ???  (in prl_client_app)  load address 0x100000000 + 0x2fafc  [0x10002fafc]
    +                                         2554 _pthread_cond_wait  (in libsystem_pthread.dylib) + 727  [0x7fff95dacc3b]
    +                                           2554 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff946eb716]

I filed a bug with Parallels on this YEARS ago. You know what they told me? Basically "we don't care, we're not going to fix it."

Here's some history.

the first "trouble ticket" bug report

I first filed this bug against them in November 2010, back when it was Parallels v6.0 (we're now on 9). They started with the usual "uninstall reinstall the app" or "reinstall parallels tools" etc. I asked them If they had attempted to reproduce the problem, but they then just said "oh update to this new version". Again I asked them point blank "did you attempt to reproduce it?", at that point, STILL not answering, they said "We will need to escalate this to the tier two support. Someone will review your issue and return to you on the expected behavior in this scenario".

Okay good, i thought, finally getting somewhere. hah. they then, and get this, said "okay reproduce the problem then send us a problem report". This makes it clear they're not actually reading my emails, because if they had they would know that parallels is HUNG at the time the problem is "reproduced". I asked them again, a but flustered by now, if they have in fact attempted to reproduce the problem.

They write back and this time I get a wee bit of traction: they tell me of a procedure to enable sending of the problem report even if the GUI of the app is hung. Okay well, good. So i send the report.

Finally, four days later i get this reply:

I submitted this case to our Development team for investigation and 
they created a ticket in the separate system to track it down. The 
investigation will continue internally and regarding this we need to 
temporary close initial support ticket until we get any news from 
them. Please ignore the message that the issue is resolved (it is 
our automatic message) because we understand that it is not 
resolved. Development team will work on the issue. As soon as we 
get any news from them or we need any additional information we 
will reopen this ticket to contact you.

So basically their policy is they CLOSE the ticket, even when it's still open. So there's no way for me to track it. They throw it "over the fence" to engineering and it's out of sight.

I point this out to them in my next email, telling them that closing the ticket is the wrong way to deal with an issue THAT IS NOT CLOSED.

They write back assuring me "It will not be lost, the Development team keeps tracking the cases and as soon as we get any news from them we will contact you".

They say "it's closed on level 1, it's now on level 2"

I admit i'm a bit frustrated at this point, I say "then i want to see that this ticket is open in "level 2" or whatever when i log in. as far as *I* know this case is just closed. i have no way to check on it except by opening another ticket on level 1??!??"

After a few more back-and-forth I convince them to keep the ticket open until development fixes the problem.

they say:

I will put this ticket on hold till we receive any news from 
our Development team regarding this case.

Well whew, right? wrong.

A month later they report they can't repro the bug and ask for clarification on the repro steps. I give it to them in excruciating detail.

A month later i get this:

This is to inform you that our product maintenance team is working 
on the issue. An internal request PDFM-21135 was create to track it 
and handle all the investigation processes. The case is entirely passed 
to developers and they will do necessary investigation and fixes. We 
do not see the reason to for us or for you to keep this ticket open  
as now all the work is done by development in their internal request 
and there is nothing to do with the ticket for support team.

So they summarily close the ticket, now i have no way to track whether they're even looking at it.

the second ticket

Another month goes by and i ask them for an update, which opens a NEW ticket.

They say something like "update to latest, it should not hang, it should work fine now"

Yes of course there's still a problem. I say "no it is still hung. i would really appreciate it if you would actually fix this bug ON PURPOSE rather than having me just keep trying the latest build to see if it "magically" fixed itself"

Okay i see i'm being a bit of a grumpy face there ☹ I am trying to meditate more, so that I can be more pleasant. Sorry about that, It's just so very frustrating to have to force quit and reboot my parallels every time i pause in the debugger.

At this point I send them a call stack dump so they can SEE the problem without even having to reproduce the bug. It really points to a very clearly defined section of code that, if they took the time to look at it, might lead them to exactly how to FIX the bug.

They then ask me to send a problem report. WTF??! I did that already, I feel like i'm getting the run-around here. Do they not review the past conversations about this?

They then reply with:

Your request has been moved to Second Line Support team. 
Thank you for your continuing interest in our product. 
We will clarify if our Product Maintenance Team can suggest 
any workaround and reply to you as soon as we have any 
news for you

Wait, i thought it already WAS in second tier? or wait, in the development tier or something??

Oh, good, i see i did apologize for being a grump:

sorry if i sounded grumpy :( i didn't mean to be like that

Anyhow, i FINALLY got a definitive answer, which sucked.

The Answer, which sucked

Our Product Maintenance concluded that when debugger set to “pause”, it locks clipboard for it`s own. And here the behavior of Parallels Desktop is not somehow out of bound, when it is not able to operate with Clipboard, while Clipboard is locked by debugger.

The problem should be workarounded by the following method: While debugger is set to pause, you can temporarily uncheck Copy&Paste/Share Mac Clipboard option in Virtual Machine > Configure > Options > Advanced. When you are finished with debugger, you can change these settings back. This should prevent Parallels Desktop of hanging.

In general, it is not planned to address the issue in the nearest Parallels Desktop updates, as it is not enough customer’s requests for now. As it was said earlier, the priority of fixes raises with the number of cases reported.

wow

Okay, like, wow. As in "areyoukiddingmerightnow?" You want me to change my prefs every time i pause in the debugger??

No, that's not the answer.

I'm a programmer, it's what i do for a living, so I have some ideas what the answer could be.

It could be that you ask if the clipboard is locked before trying to use it. It could be that you install a daemon as an intermediary between parallels and the clipboard, so that if the clipboard is locked, the daemon hangs and not parallels. There are other ways around the problem.

tell me why all other apps in the guest OS can still access the clipboard? if THEY can do it, why can parallels not do it?

I tell them that that "workaround" is NO solution in any sense of the word. A few more back and forth and this is what they say:

We understand that you are not satisfied with such outcome 
of the issue and disagree to close the request, but there is no 
solution to provide.

If the issue does not allow you to continue using our product,  
we can offer you an option to return your copy of Parallels 
Desktop and get a refund for it

So they basically just give up, and say "we don't need your money".

I'm desperate so i attempt to solve the problem for them, i say:

you are requesting a mutex that is taken on another thread.

instead of requesting to lock the mutex, use "trylock" instead, 
this will return FALSE if you can not grab the mutex.  in that 
case, just beep instead of hanging, it's quite a simple code fix.

their reply:

Thank you for your investigation and valuable suggestions, we 
clarified this point with Parallels Development Team. They are 
not going to change this part of the code in the nearest future 
because it affects other vast important functionality of the product

pardon my french but that sounds to me like a nice big middle finger.

the close the SECOND ticket.

third ticket

in september of that year, i try again:

they skip to the end right away this time:

We have passed the issue details to Parallels Maintenance 
Team and they have created an internal ticket in their 
database PDFM-21135. We cannot estimate how long it 
will take for them to give us further instructions

Then they move to close the ticket.

I re-open it and explain to them how broken that system is, closing an issue that is NOT resolved. they come back and unequivocally reassure me:

your issue was reported to our development and currently 
they are working on the solution, and we may expect the 
fix in one of further updates

Okay so i'd really like to hold you to that, parallels, right there you made me a promise.

fourth ticket

I have just now (feb 2014) opened another ticket. we shall see.

OMG FIXED!!!!

Just one day later, i "somehow" got the attention of two engineers at Parallels, who correctly diagnosed the problem and proposed a potential work around for me.
The solution worked!