Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repeatable crash in syntax highlighter with embed. #2342

Closed
Thom1729 opened this issue Jun 1, 2018 · 12 comments
Closed

Repeatable crash in syntax highlighter with embed. #2342

Thom1729 opened this issue Jun 1, 2018 · 12 comments

Comments

@Thom1729
Copy link

Thom1729 commented Jun 1, 2018

Summary

A certain pattern in a syntax definition, combined with certain input, causes Sublime to crash.

Steps to reproduce

Use the following syntax definition:

%YAML 1.2
---
name: Test Crash
scope: source.test-crash
contexts:
  main:
    - match: A
      embed: embedded
      escape: Z

  embedded:
    - match: a
      embed: dontcare
      escape: z

  dontcare:
    - match: x

Open a new tab. Select the above syntax definition. The following inputs will cause Sublime to crash (\n denotes newline):

  • AaZ.
  • A a Z.
  • A\naZ

The following will not:

  • AazZ
  • Aa\nZ
  • A\nazZ

Platform

Sublime 3175 x64
Fedora 25

@keith-hall
Copy link
Collaborator

also confirmed on Win7 x64.

@rwols
Copy link

rwols commented Sep 17, 2018

Can confirm this on macOS too :). Good luck debugging.

@keith-hall
Copy link
Collaborator

also somewhat related to this, is the prototype handling:

%YAML 1.2
---
# See http://www.sublimetext.com/docs/3/syntax.html
scope: source.test-embed-prototype-handling
contexts:
  prototype:
    - match: foo
      scope: keyword
      push: foo
    - match: hello
      scope: constant.language
      embed: inside
      escape: world
      escape_captures:
        0: constant.language
  main:
    - match: ''
  foo:
    - match: bar
      scope: bar
      pop: true
  inside:
    - match: \d+
      scope: constant.numeric

if one was to use the above syntax definition and type foofoobar, the second foo is not scoped, because the prototype context isn't applied in contexts which are included/set/pushed from the prototype context. (i.e. it is like the foo context has meta_include_prototype: false automatically applied to it. But, typing hello123hello is enough to make ST crash, which makes me wonder, shouldn't ST apply that same logic here, and not include the prototype context in contexts embedded "under" the prototype context? so in this case, imply meta_include_prototype: false in the inside context as well.

@Thom1729
Copy link
Author

@wbond Just bumping this because it's probably the cause of an easily-produced crash when using the core Java syntax. Not sure whether this would constitute a “critical” bug under the circumstances.

@wbond
Copy link
Member

wbond commented Dec 10, 2018

Thanks for the reminder - I saw a crash report recently around lexing, so I made a mental note of coming back to this soon to see if fixing this solves the crash that was reported.

@wbond
Copy link
Member

wbond commented Dec 15, 2018

Hah, so adding this test case hit an assertion in our debug build. 🙂

@wbond
Copy link
Member

wbond commented Dec 17, 2018

And Oniguruma is the issue. It is over-reading the input string. It appears it was a caching layer on top of Oniguruma.

@berkus
Copy link

berkus commented Jan 7, 2019

So is this fixed? I consistently couldn't open Java files - when clicking one ST3 just crashes.

@gardelea
Copy link

while this bug is being worked on, is there any action we can take in the meantime to be able to use Sublime for Java again ?
for example, would invalidating/rebuilding the cache on top of Oniguruma temporarily prevent Sublime from crashing ?

@wbond
Copy link
Member

wbond commented Jan 16, 2019

@gardelea Yes, the stable build of Sublime Text is the solution until we have the next dev build (which is hopefully within the next week).

@gardelea
Copy link

@wbond ah ha, the stable build, of course !
thanks for the quick reply

@wbond wbond added this to the Build 3186 milestone Jan 18, 2019
@wbond
Copy link
Member

wbond commented Jan 18, 2019

This was fixed in build 3186

@wbond wbond closed this as completed Jan 18, 2019
@wbond wbond added the R: fixed label Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants