internal errors that block UI-Thread

[Simon Schäfer]

After updating to the last nightly build, I get some internal build
errors.

They are extremely problematic because they can block the UI-Thread for
about 5 to 10 seconds. First I thought it is related to the bug that
lets semantic highlighting running forever but after deactivating
semantic highlighting the errors still occur. It seems that the errors
are unproblematic on simple save actions but when I want to use
hyperlinking for example the UI-Thread is blocked for several seconds.

The errors:http://codepad.org/yz1UHjeZ

The first two exceptions occur always while the last two belong to
hyperlinking.

I use 2.10 nightly and eclipse 3.7. Is this bug already known?

[iulian dragos]

Hi Simon,

I've seen similar, it's a binary incompatibility between different
versions of 2.10 nightlies. It looks like your system has an older
scala-refactoring build, that is incompatible with the compiler
bundle. Can you paste here the version of the scala.library/compiler
bundle, and also scala-refactoring? (the first 2 can easily be
copy-pasted from the Scala/Report A Bug dialog).

The second is not an exception per se, it's not thrown: it's a timeout
in ask-option, and we print the stack trace for debugging purposes.

It would be great to get to the bottom of this..

thanks,
iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Simon Schäfer]

The information from scala-ide:

Scala plugin version: 2.1.0.nightly-2_10-201210070323-4d78173

Scala compiler version: 2.10.0.v20121005-094526-bfde8c79cf
Scala library version: 2.10.0.v20121005-094526-bfde8c79cf
Eclipse version: 3.7.2.v201202080800

Eclipse' Plug-in Registry tells me that I use:

org.scala-refactoring.library (0.5.0.201210070506-null)

[iulian dragos]

Thanks Simon,

I think it's a missing Import-Package in scala-refactoring. I'll
prepare a fix and let you know.

iulian

[Mirco Dotta]

> org.scala-refactoring.library (0.5.0.201210070506-null)

Oh, the null at the end was supposed to be the git hash. Fixing this now, thanks Simon!

[virtualeyes]

and this has nothing to do with sematic highlighting forever issue?

A nightly from a couple of days ago made progress in the sense that after a few minutes the hung thread is resolved (interestingly, only when I shift focus away from the IDE and do something else like check email).

[Mirco Dotta]

On Oct 7, 2012, at 2:22 PM, iulian dragos wrote:

> Thanks Simon,
>
> I think it's a missing Import-Package in scala-refactoring. I'll
> prepare a fix and let you know.

And this is a related ticket: https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001258

I guess the fix is to add a `scala.reflect.io;resolution:=optional` in the scala-refactoring MANIFEST. I'm already
working on a small patch for fixing the `null` git-hash suffix, I could also push this little fix together.

[iulian dragos]

On Sun, Oct 7, 2012 at 2:41 PM, virtualeyes <sit...@gmail.com> wrote:
> and this has nothing to do with sematic highlighting forever issue?
>
> A nightly from a couple of days ago made progress in the sense that after a
> few minutes the hung thread is resolved (interestingly, only when I shift
> focus away from the IDE and do something else like check email).

The timeout is 10 seconds. I don't think it has anything to do with the focus.

iulian

[Eugene Burmako]

Is this an OSGI problem then?

[iulian dragos]

On Sun, Oct 7, 2012 at 3:00 PM, Mirco Dotta <mirco...@typesafe.com> wrote:
>
> On Oct 7, 2012, at 2:22 PM, iulian dragos wrote:
>
>> Thanks Simon,
>>
>> I think it's a missing Import-Package in scala-refactoring. I'll
>> prepare a fix and let you know.
>
> And this is a related ticket: https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001258

Thanks for digging it out.

I already pushed a fix, waiting for the build to finish. If it's ok,
I'll close the ticket.

iulian

[Mirco Dotta]

On Oct 7, 2012, at 3:02 PM, iulian dragos wrote:

> On Sun, Oct 7, 2012 at 3:00 PM, Mirco Dotta <mirco...@typesafe.com> wrote:
>>
>> On Oct 7, 2012, at 2:22 PM, iulian dragos wrote:
>>
>>> Thanks Simon,
>>>
>>> I think it's a missing Import-Package in scala-refactoring. I'll
>>> prepare a fix and let you know.
>>
>> And this is a related ticket: https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001258
>
> Thanks for digging it out.
>
> I already pushed a fix, waiting for the build to finish. If it's ok,
> I'll close the ticket.

Ok!

[iulian dragos]

On Sun, Oct 7, 2012 at 3:02 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
> Is this an OSGI problem then?
>

Yes. It's fixed now, upgrade your nightlies, gentlemen!

iulian

[Simon Schäfer]

Thanks, works well!

The remaining problem now is that `askOption` can have a timeout. Any
ideas on how to fix that?

[iulian dragos]

On Sun, Oct 7, 2012 at 5:23 PM, Simon Schäfer <ma...@antoras.de> wrote:

Thanks, works well!

The remaining problem now is that `askOption` can have a timeout. Any ideas on how to fix that?

The timeout is needed because we couldn't track down and fix a race condition that is plaguing the IDE for months now: some `ask` calls are never answered by the compiler, usually when the compiler is shutdown and restarted. In order not to have freezes or threads that hang, we added the timeout. I recently had a little breakthrough and been able to reproduce it in the debugger, but we don't have a fix yet.

Regardless of when this is fixed, I think the timeout is necessary for all operations that end up blocking the UI thread. Most users would gladly trade-off some precision for snappiness. 

iulian

 

On Sun 07 Oct 2012 03:36:53 PM CEST, iulian dragos wrote:

On Sun, Oct 7, 2012 at 3:02 PM, Eugene Burmako <eugene....@epfl.ch> wrote:

Is this an OSGI problem then?

Yes. It's fixed now, upgrade your nightlies, gentlemen!

iulian

[Simon Schäfer]

I don't critisize the timeouts in general - my problem is only that
they occur now for some days on nearly each save action, which is
extremely annoying.

Is the timeout a simple constant that can be edited? If yes, where can
I find it? Maybe a change can be useful on my local build (or at least
in the debugger).

[Mirco Dotta]

I don't critisize the timeouts in general - my problem is only that they occur now for some days on nearly each save action, which is extremely annoying.

Simon, I share your pain, and we need to fix it.

Is the timeout a simple constant that can be edited? If yes, where can I find it? Maybe a change can be useful on my local build (or at least in the debugger).

No, it isn't a user-editable constant. The default value is hardcoded in `ScalaPresentationCompiler.askOption`, and it is currently set to 10s, which is probably 

not a good default in many cases.

I think we need to tune the timeout value on a case-by-case need. For instance, askOption calls in semantic highlighting should give back an answer almost 

instantaneously, as this calls should operate on an already type checked tree. Hence, I'd say that a good default for them should be 100/200ms.

Also, it would be much better to log timeouts in the scala-ide.log file alone (all those `Timeout in askOption` entries in the Error Log View are madness :))

I'm planning to have a look at it as soon as I nail down this beauty https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001265

But, if you want it fix it right away, please feel free to hack on ;)

-- Mirco

---------------

Mirco Dotta

Typesafe - The software stack for applications that scale

PSE-D, 1015 Lausanne, Switzerland

Work: +41 (0)21 691 49 65

Twitter: @mircodotta

[Simon Schäfer]

On Mon 08 Oct 2012 05:21:11 PM CEST, Mirco Dotta wrote:
>> I don't critisize the timeouts in general - my problem is only that
>> they occur now for some days on nearly each save action, which is
>> extremely annoying.
>
> Simon, I share your pain, and we need to fix it.
>
>> Is the timeout a simple constant that can be edited? If yes, where
>> can I find it? Maybe a change can be useful on my local build (or at
>> least in the debugger).
>
> No, it isn't a user-editable constant. The default value is hardcoded
> in `ScalaPresentationCompiler.askOption`, and it is currently set to
> 10s, which is probably
> not a good default in many cases.
> I think we need to tune the timeout value on a case-by-case need. For
> instance, askOption calls in semantic highlighting should give back an
> answer almost
> instantaneously, as this calls should operate on an already
> type checked tree. Hence, I'd say that a good default for them should
> be 100/200ms.
>
> Also, it would be much better to log timeouts in the scala-ide.log
> file alone (all those `Timeout in askOption` entries in the Error Log
> View are madness :))
>
> I'm planning to have a look at it as soon as I nail down this beauty
> https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001265

Yeah, another annoying bug.

> But, if you want it fix it right away, please feel free to hack on ;)

It seems this is a bug in the compiler, which I think is impossible for
me to fix. ;)

> Typesafe <http://www.typesafe.com/> - The software stack for

[iulian dragos]

On Sun, Oct 7, 2012 at 6:56 PM, virtualeyes <sit...@gmail.com> wrote:

k, can't get anything done with semantic highlighting enabled, hung thread issue just drags IDE performance to a crawl.

This issue has been fixed in recent nightlies. Can you please give it another try?

iulian

 

Have semantic highlighting disabled, pretty snappy, even with incremental builds -- the main drawback is of course, black code canvas against a bunch of white text ;-(

Hopefully the issue will get sorted, semantic highlighting is a huge plus.

Thanks

[Simon Schäfer]

For me, it seems to be fixed. Thanks very much for the fix!

> >> >>> The errors:http://codepad.org/__yz1UHjeZ