internal scalac crashes in eclipse plugin

I saw this problem earlier today, and when I double clicked on that
error message, it provided a lengthy stack trace indicating that a class
that some other class depended on was missing. In my case it was because
I had added the scalax jar to my project but not the slf4j-api jar that
it depends on.

-Tupshin

Vlad Patryshev wrote:
> Hi,
>
> I was having weird problems with eclipse and scala plugin in my
> workspace (eclipse was hanging); so I created a new workspace, copied
> over just one scala file over there, and kaboom, all I'm getting now
> is this:
>
> MESSAGE Build compiler (scalac) crashed
>
> That's what I see in the log.
>
> It does not depend on my scala code.
>
> I bet someone saw it before. What would be a good solution? Switch to
> netbeans?
>
> Thanks,
> -Vlad

On Tue, Feb 17, 2009 at 6:17 AM, Vlad Patryshev wrote:
> I was having weird problems with eclipse and scala plugin in my workspace
> (eclipse was hanging); so I created a new workspace, copied over just one
> scala file over there, and kaboom, all I'm getting now is this:
> MESSAGE Build compiler (scalac) crashed
> That's what I see in the log.
> It does not depend on my scala code.
> I bet someone saw it before. What would be a good solution? Switch to
> netbeans?

You could try reporting a bug with a reproducible test case.

In your original workspace where you were experiencing a hanging
build, try deleting your projects (hidden) .manager directory and they
try building again.

Wrt the scalac crash in the second workspace ... can you veryify that
that file compiles without a crash (compile errors are fine) using the
command line tools.

Cheers,

Miles

On Tue, Feb 17, 2009 at 6:35 AM, Tupshin Harper wrote:
> I saw this problem earlier today, and when I double clicked on that error
> message, it provided a lengthy stack trace indicating that a class that some
> other class depended on was missing. In my case it was because I had added
> the scalax jar to my project but not the slf4j-api jar that it depends on.

Can you reproduce this with the command line tools? Either way, a
compiler crash is a bug (maybe against scalac, maybe against the
Eclipse plugin) and needs to be reported.

Cheers,

Miles

On Tue, Feb 17, 2009 at 3:35 AM, Tupshin Harper <tupshin@tupshin.com> wrote:

I saw this problem earlier today, and when I double clicked on that error message, it provided a lengthy stack trace indicating that a class that some other class depended on was missing. In my case it was because I had added the scalax jar to my project but not the slf4j-api jar that it depends on.

-Tupshin

Vlad Patryshev wrote:

Hi,

I was having weird problems with eclipse and scala plugin in my workspace (eclipse was hanging); so I created a new workspace, copied over just one scala file over there, and kaboom, all I'm getting now is this:

MESSAGE Build compiler (scalac) crashed

That's what I see in the log.

It does not depend on my scala code.

I bet someone saw it before. What would be a good solution? Switch to netbeans?

Thanks,
-Vlad

I have noticed that some code patterns do cause problems. Check your files and find the one that triggers the problem, then start commenting code until you find what causes it to break. I did this once, but the plugin is constantly improving so it's sometime hard to reproduce the problem.

My experience with the plugin shows that it sometime behave badly.  Overall it's good but not bullet proof. From 2.7.2 -> 2.7.3 some of the issues I had were gone.

When it behave strangely I try the following:
1) Close and open the project (this clears some double files, and failing of the highlight)
2) Clean the project and rebuild (particularly important when you refactor classes)
3) remove the files in the .manager directory, then clean and rebuild (when all else fails)

I recommend opening the ticket, but finding the pattern that make's it crash is hard.

Thomas

Actually scala compiler does not fail on that code. It's the plugin that reports failure, and I got a feeling the plugin just cannot launch scalac properly. Will investigate.

2009/2/18 Thomas Sant Ana <mailleux@gmail.com>

On Tue, Feb 17, 2009 at 3:35 AM, Tupshin Harper <tupshin@tupshin.com> wrote:

I saw this problem earlier today, and when I double clicked on that error message, it provided a lengthy stack trace indicating that a class that some other class depended on was missing. In my case it was because I had added the scalax jar to my project but not the slf4j-api jar that it depends on.

That was my first action, remove everything from the file and try to compile something like class Hello { val i = 1 } 

-Tupshin

Vlad Patryshev wrote:

Hi,

I was having weird problems with eclipse and scala plugin in my workspace (eclipse was hanging); so I created a new workspace, copied over just one scala file over there, and kaboom, all I'm getting now is this:

MESSAGE Build compiler (scalac) crashed

That's what I see in the log.

It does not depend on my scala code.

I bet someone saw it before. What would be a good solution? Switch to netbeans?

Thanks,
-Vlad

I have noticed that some code patterns do cause problems. Check your files and find the one that triggers the problem, then start commenting code until you find what causes it to break. I did this once, but the plugin is constantly improving so it's sometime hard to reproduce the problem.

My experience with the plugin shows that it sometime behave badly.  Overall it's good but not bullet proof. From 2.7.2 -> 2.7.3 some of the issues I had were gone.

When it behave strangely I try the following:
1) Close and open the project (this clears some double files, and failing of the highlight)
2) Clean the project and rebuild (particularly important when you refactor classes)
3) remove the files in the .manager directory, then clean and rebuild (when all else fails)

I recommend opening the ticket, but finding the pattern that make's it crash is hard.

Thomas

--
Thanks,
-Vlad

On Wed, Feb 18, 2009 at 1:36 PM, Vlad Patryshev <vpatryshev@gmail.com> wrote:

Actually scala compiler does not fail on that code. It's the plugin that reports failure, and I got a feeling the plugin just cannot launch scalac properly. Will investigate.

I had the same problem with my bug report. Command line scalac will compile just fine. But it will cause problem in the plugin. I think the problem is that for some codes patterns when the plugin navigates the parser tree of the compile it either get's lost or fail to handle some borderline cases.

This has improved in every release of the plugin, but I felt somewhat disappointed when I nailed down the problem and it was gone on the next version without any real confirmation on how it went away. The upside is that the plugin is improving, the downside is that the support process is not capable of handling all the little glitches, like:
 - I've seen syntax highlighting stop (on parts of the code)
 - Build stop halfway and general bogus error message when I refactor classes (have to keep clean and rebuild, until I fixed all of the real code breaks).

To me the plugin is very good and workt perfectly almost all the time. My take, is wait for the new release and work around the plugin issues. I sure think that it would be nice to improve the way problems are reported on the plugin, for example: if it runs ok on Scalac, but causes problem on Eclipse, IMHO it's either a plugin issue, or a plugin-compiler  interface issue.

On some of my larger project nailing down the trouble code is hard, and going to that pain just to see the issue bounced around and closed for disappearing on the next release does not make me want to spend the effort of reporting a nice little toy case that allows support to investigate.

Sorry for venting some frustration here, I know the plugin team is working hard, and I love the way it works now. But if we are to report these minor gluitches, the process has to improve.

Thomas
 

On Wed, Feb 18, 2009 at 5:32 PM, Thomas Sant Ana wrote:
> On some of my larger project nailing down the trouble code is hard, and
> going to that pain just to see the issue bounced around and closed for
> disappearing on the next release does not make me want to spend the effort
> of reporting a nice little toy case that allows support to investigate.
>
> Sorry for venting some frustration here, I know the plugin team is working
> hard, and I love the way it works now. But if we are to report these minor
> gluitches, the process has to improve.

Umm ... I'm having a little trouble fully grokking this ...

You seem to be _complaining_ that by the time you get around to
reporting your problems they're already fixed?!? ;-)

Cheers,

Miles

On Wed, Feb 18, 2009 at 2:43 PM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Feb 18, 2009 at 5:32 PM, Thomas Sant Ana <mailleux@gmail.com> wrote:
> On some of my larger project nailing down the trouble code is hard, and
> going to that pain just to see the issue bounced around and closed for
> disappearing on the next release does not make me want to spend the effort
> of reporting a nice little toy case that allows support to investigate.
>
> Sorry for venting some frustration here, I know the plugin team is working
> hard, and I love the way it works now. But if we are to report these minor
> gluitches, the process has to improve.

Umm ... I'm having a little trouble fully grokking this ...

You seem to be _complaining_ that by the time you get around to
reporting your problems they're already fixed?!? ;-)

No.  It takes a lot of time to place a good bug report (you don't want to get a project with 100 files attached). Once it's reported, the issue gets sent arround on the "not the plugin, the compiler", "not compiler, the plugin" tour. And the new release of the plugin miraculously does not have the bug. There is no "found it, fixed it", it just goes away.

In general I'm ok with that, but I think that the issues are not handled formally, they get fixed as a by-product of general changes to the plugin code. So it's frustrating, spending an hour or two to isolate the problem, and not have it really looked at. That's my point.

I have an file that every time a swith to it or recompile, then go to the Launch button (the > Icon) gives me an:

An internal error occurred during: "Compute launch button tooltip".
java.lang.NullPointerException


I looked at the trace and it's something in the plugin. But Isolationg this is going to take time. And because of my past experience I think its a better use of my time to wait for it to go away on the next release, and work around it, then to try and open an bug. I don't think this helps the project, but out of 3 issues I open on the plugin queue, all 3 where closed by new releases, with no real information on what caused it, which makes sense. An two bounces queues (IIRC). It's a matter of trust in the system. I think it would be great to improve bug reporting for the pluggin. However it may not be the correct time, there are alot of changes on each release (not just changing the backend compiler support).

Thoma

On Wed, Feb 18, 2009 at 6:36 PM, Thomas Sant Ana wrote:
>> You seem to be _complaining_ that by the time you get around to
>> reporting your problems they're already fixed?!? ;-)
>
> No. It takes a lot of time to place a good bug report (you don't want to
> get a project with 100 files attached). Once it's reported, the issue gets
> sent arround on the "not the plugin, the compiler", "not compiler, the
> plugin" tour. And the new release of the plugin miraculously does not have
> the bug. There is no "found it, fixed it", it just goes away.

In which case it's quite likely that it actually _was_ a compiler bug
that was fixed in the same release.

So the problem seems to be that,

* You reported a compiler bug against the Eclipse plugin.

* I closed the bug as invalid because it's a compiler bug not an
Eclipse bug. Assuming the compiler bug was in Trac I probably would
have pointed to that ticket at the same time ... if not, then my bad.

* The compiler bug was closed independently and you weren't notified
because this wasn't your ticket and you weren't cc'd on the ticket
corresponding to the underlying bug.

I can understand your frustration, but I'm not really sure what I or
anyone else can do about the problem. The best I can do is suggest is
that you follow Trac a little more closely.

Maybe we can make this a little more concrete ... exactly which
ticket(s) are we talking about here?

Cheers,

Miles

On Wed, Feb 18, 2009 at 3:51 PM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Feb 18, 2009 at 6:36 PM, Thomas Sant Ana <mailleux@gmail.com> wrote:
>> You seem to be _complaining_ that by the time you get around to
>> reporting your problems they're already fixed?!? ;-)
>
> No.  It takes a lot of time to place a good bug report (you don't want to
> get a project with 100 files attached). Once it's reported, the issue gets
> sent arround on the "not the plugin, the compiler", "not compiler, the
> plugin" tour. And the new release of the plugin miraculously does not have
> the bug. There is no "found it, fixed it", it just goes away.

In which case it's quite likely that it actually _was_ a compiler bug
that was fixed in the same release.

So the problem seems to be that,

* You reported a compiler bug against the Eclipse plugin.

 

* I closed the bug as invalid because it's a compiler bug not an
Eclipse bug. Assuming the compiler bug was in Trac I probably would
have pointed to that ticket at the same time ... if not, then my bad.

Not the case. They are not necessarily compiler errors, they work standalone, they generated code.

They were closed with my comments too. And I agreed wholeheartedly with the action.
 

* The compiler bug was closed independently and you weren't notified
because this wasn't your ticket and you weren't cc'd on the ticket
corresponding to the underlying bug.

In 2 of the cases the bug did not appear in the standalone compiler (IIRC 1288, 1576).
I never seen any of them move to the compiler queue.
 

I can understand your frustration, but I'm not really sure what I or
anyone else can do about the problem. The best I can do is suggest is
that you follow Trac a little more closely.

I generally do. In one case I was having trouble updating the pluggin (due to some issues in eclipse I discover later). I try the best I can to describe the issue, and if possible give a way of making them reproducible. I worked for year in tech support for software, and I understand the value of these things.

Maybe we can make this a little more concrete ... exactly which
ticket(s) are we talking about here?

#1283 Build compiler (scalac) crashed defect closed normal Eclipse plugin
#1287 Error message when opening Scala Project defect closed normal Eclipse plugin -- #1288 Multiple error on Scala and javax.swing project defect closed normal Eclipse plugin -- #1576 Plugin syntax highlighting and code completion failures with stackoverflow defect closed normal Eclipse plugin

 Those given, this is just my general feeling. I may be wrong, or not have a full understanding of how the problems happens. I try to open them as detailed as possible, to make it easier to find and reproduce the bug. 1283 is an example where not enough info was available, and I thing that release was the first. 1576 is the one that got me annoyed (despite it being fixed on 2.7.3)

That said, I like the work you guys are doing. And I would mind reporting every single weird behavior (like 4 lines in the middle out of 50 being black (no syntax highlight on those lines)). But only it its going to be valid for you guys. If there is a lot of significant changes, and the code is evolving to fast to be worthwhile to look at those glitches, I understand. If you want make each release "bullet proof", then this kind of reporting is important.

I have to let some things clear: 1) I like the plugin, and it's really a good tool; 2) it's evolving quickly and each release is significantly better than the previous; 3) I like the work you guys are doing; 4) Scala is really cool!

One last comment is that scala allows lots of code pattern to be used, you mix closure, xml, classes, and custom operators. There are going to be cases where someone uses something (correctly) in a way you didn't expect.

We can take this out of the list, if you think it's better.

Thomas

On Wed, Feb 18, 2009 at 7:23 PM, Thomas Sant Ana wrote:
>> Maybe we can make this a little more concrete ... exactly which
>> ticket(s) are we talking about here?
>
> #1283 Build compiler (scalac) crashed defect closed normal Eclipse plugin
> #1287 Error message when opening Scala Project defect closed normal Eclipse
> plugin --
> #1288 Multiple error on Scala and javax.swing project defect closed normal
> Eclipse plugin --
> #1576 Plugin syntax highlighting and code completion failures with
> stackoverflow defect closed normal Eclipse plugin

OK, now I'm really confused. You should have been cc'd on all those
bugs, so you'd have had the earliest possible notification of the bug
being officially fixed.

What didn't happen that you would have like to have happened?

Cheers,

Miles