You might be exceeding the timeout on heroku.

edit this is totally wrong upon reflection

@Ch4s3 thanks for the suggestion, but that's not it. If I remove the --dev it works, and with --dev it's actually faster. And I work at Heroku :)

@jkutner you might want to not use --dev and try -X-C to see whether this is strictly an interpreter bug or whether the other options of --dev are causing this. Best case outcome is it is an interpreter bug.

@enebo it works with -X-C. what does that mean?

Ahh, @jkutner I should have recognized you from our buildpack discussion.

For future googlers:
-X-C only turns off the JIT. Using --dev turns off JIT, but also:

• disables invokeDynamic
• disables JRuby's JVM bytecode compiler
• sets client mode, or tiered compilation depending on host system (probably the latter on heroku)

My guess is that its related to invokeDynamic. I suspect turning that off kills the ability of the JVM to duck type and do some of the things that Sprockets relies upon. That might explain why it is blowing up building the AST. This is just a hunch though, and I could be way off.

@jkutner @Ch4s3 invokedynamic has been disabled by default for a while now so unless it has been enabled then that probably is not it. It was disabled because warmup time on invokedynamic was really slow for big apps (like basically any Rails app). Also most of the invokedynamic options are done at JIT time (although not all).

@jkutner Is it possible asset compilation uses threads? LocalAsgnNode is just what you would think it would be. It is trying to assign an 'b = 1' or something and when grabbing the predefined depth and offset it is running into the wrong scope. You could recompile and catch this NPE in LocalAsgnNode and print out the file and source (getPosition() on that node).

@enebo That's interesting to know.

Speaking of threads, could this be the issue.

@Ch4s3 I don't know. If I had to guess we have had issues in the past with eval with bindings which displayed weird scoping issues. Combine that with threads? Getting an actual source location will end up being a huge clue.

@enebo I'm kind of grasping here, but I've had similar issues as well so I'm interested in reading through source and stack traces to see if I can help.

It might be interesting to walk through the stack with and without --dev.

@Ch4s3 @enebo thanks for looking at this. I've tried like heck to reproduce it without the customer's proprietary code, but have not had any luck.

There is no more stacktrace info than what I've shown above. The only other thing I know is that it happens after or during scss compile because the output right before the error is a warning about application.scss.

Is there any other info I can provide that might help determine the source? I'm not super familiar with sprockets :(

this piece is likely not longer relevant (with recent 9K). @jkutner has the time to close 🛬 ?

Ancient issue and I am closing barring any new info.