Crash on OSX w/ No files open

[Nooshu]

Hello, I seem to be having a problem with the package at the moment. I'm starting a project scan, it starts scanning but crashes ST3 (build 3065) every time it gets to around 13,300 files scanned. This is repeatable and happens every time.

Is there anywhere I can look for a log file to see why the crash is happening? Maybe it is a conflict with another package? I'm happy to post the log file to help get to the bottom of it.

Thanks.

[jonathanrdelgado]

As in the entire ST3 instance crashes? I've never seen that behavior before. If that is true, then this sounds like an issue with Sublime itself, packages are supposed to be run in a sandbox.

If you meant that it just stopped scanning, but left the windows opened, try hitting ctrl + ~ and give me the error.

[Nooshu]

Hi jonathandelgado,

Yeah the whole instance crashes for some reason. I've only managed to run the package successfully once. After that it has just crashed. I'll dig around Sublime and look for some logs, see if I can send anything over to debug the issue.

[jonathanrdelgado]

Could you give me some environment details? OS, Plugins, Config, Possibly even the files you are attempting to scan?

On windows, when Sublime crashes, i'm pretty sure it writes a dump file to the currently active project directory. For mac, I know there is some kind of internal crash report. Details from either would be helpful.

[jonathanrdelgado]

@Nooshu Any update to this?

[wbyoung]

@jonathandelgado I'm experiencing a crash as well. No crash report is being generated in the standard locations for Mac OS X. Happy to send more details. This only started happening recently.

[jonathanrdelgado]

@wbyoung Any details you can provide would be helpful, but I doubt I could do much in terms of a solution without some debug information.

[wbyoung]

I have the following settings:

{
    "color_scheme": "Packages/Color Scheme - Default/Dawn.tmTheme",
    "dictionary": "Packages/Language - English/en_US.dic",
    "file_exclude_patterns":
    [
        ".*"
    ],
    "folder_exclude_patterns":
    [
        ".*",
        "tmp",
        "out",
        "node_modules",
        "bower_components"
    ],
    "ignored_packages":
    [
        "Vintage"
    ],
    "spell_check": true,
    "tab_size": 2,
    "theme": "Soda Light.sublime-theme",
    "todoreview":
    {
        "exclude_folders":
        [
            "tmp",
            "out",
            "*/.*",
            "*/coverage/*",
            "*/node_modules/*",
            "*/bower_components/*"
        ]
    },
    "translate_tabs_to_spaces": true
}

I can send more debug info if you'd like, but I don't know where to find it. How do you normally debug while you're working on the plugin?

[wbyoung]

@jonathandelgado hmm… just tried it again and it's working. It seems to be crashing when there are no open files for a project. It worked as well when the preferences were open or an untitled file. So not just a file open that's contained within the project — just any file.

[jonathanrdelgado]

Oh, this might be a re-introduction of #22, thanks for the additional information @wbyoung

I'll look into it next time I have access to OSX

[wbyoung]

@jonathandelgado thanks!

[jonathanrdelgado]

Had access to a machine today - honestly have no idea what the problem is. I tried looking into the original fix and had no luck.

As far as I can tell, this only occurs on OSX when no files are open. Debugging the crash only shows an issue with python threading. I highly doubt this is an issue with the plugin, but more with SublimeText's handling of threading.

Any help would be appreciated.

[wbyoung]

@jonathandelgado I'm not familiar with writing Sublime plugins, but if you can point me in the right direction, I'll take a look. Where would I edit the plugin & where could I see the output of any print statements and/or stack traces?

[jonathanrdelgado]

@wbyoung I honestly don't know where to start. Print statements print to console (Ctrl + ~) but when the system crashes, those are erased. There are specific debugging tools for viewing mac crash files, but all just give me generic python threading issues.

I just meant if anyone knew what the issue was, let me know. No need to waste time on this, we know how to avoid the issue, and that is more than enough for now!

[wbyoung]

@jonathandelgado restarted my computer, Sublime reported an update of TodoReview & it's no longer crashing.

[wbyoung]

@jonathandelgado spoke too soon. It's still crashing.

[wbyoung]

@jonathandelgado it's crashing when TodoReviewRender, a subclass of sublime_plugin.TextCommand uses new_file() on the active window.

Putting just sublime.active_window().new_file() inside of the run of the review renderer causes the app to crash. Putting the same code in TodoReviewCommand#render just before the run_command works completely fine.

Any thoughts?

[wbyoung]

@jonathandelgado I tried it without the threading enabled and it worked just fine as well. That's not consistent with the Sublime API documentation. It seems possible that this is a bug with the Sublime API & not in this project's code.

Also, having the render occur back on the main thread does not fix the issue of being able to call new_file inside of the TodoReviewRender.

Do you know how to get old versions of Sublime Text to test that assumption?

[jonathanrdelgado]

@wbyoung Yeah, that sounds like the same conclusion I reached in the #22 issue. I went back and looked at the code changes and honestly have no idea how my modification resolved the issue. I've tried a few variations, but to no avail.

I know it has to do with the threading, as you mentioned, but if I remove the threading, all of the scanning will be done synchronously, which is really abusive to the end-user in my opinion. I think the most important thing we can do for debugging is to find out why this is only occurring when no files are opened.

I've talked this issue over with some other developers in the community and we've all pretty much agreed that this is an issue with SublimeText or Python, not only because of the inconsistencies with the API as you pointed out, but the actual application crashing. All errors should be caught within sublime and displayed in the console. It seems this iterates an instability within perhaps python itself on the OSX platform, since this issue cannot be duplicated on Windows.

You can download ST2 at http://www.sublimetext.com/2, by the way.

Honestly, worst comes to worst on this, I might just add a logic block that determines if the crash is going to occur (On OSX and scanning with no files open) and display an error message, catching the error before killing the process.

I appreciate the time you are spending on this matter by the way!

[wbyoung]

@jonathandelgado it's not an exception that's catchable. That was one of the first things that I tried, so your thoughts about threading and Python/OS X/Sublime Text seem to align with what I saw.

I don't know how much of Sublime Text is in Python, but it seems possible to me that the call to new_file() would trigger something internal within the core app code that would cause the app to crash without any issues.

All Python errors seem to be getting caught properly while I was using the app. I'd lean toward it being a Sublime Text core issue that only affects OS X.

I still wasn't able to find any sort of core dump or crash report for the main Sublime Text app & didn't have any luck attaching it to a debugger.

Any thoughts on opening a communication channel with Jon Skinner or getting someone who may be able to help look into core issues?

[jonathanrdelgado]

@wbyoung Yeah, I agree. I'll most likely just add the error message I mentioned in the next release as I don't think we're going to come up with a real solution.

If you have a way to communicate with Jon directly, please do. I don't think I've ever seen him in IRC.

[wbyoung]

No new info, but I just wanted to paste in the code I used to debug this a bit in case it helps anyone:

f = open('/Users/myusername/Desktop/todoreview.log', 'a')
log_level = 0
def log(message):
  global log_level
  def close():
    global log_level
    log_level -= 1
    f.write('  ' * log_level)
    f.write(message)
    f.write(' <exit')
    f.write('\n')
    f.flush()
  f.write('  ' * log_level)
  f.write(message)
  f.write('\n')
  f.flush()
  log_level += 1
  return close

It's not very elegant, but it allowed me to trace the execution of the program.

[jonathanrdelgado]

@wbyoung Thanks for sharing!

[jonathanrdelgado]

Can't believe it's been a year since this issue was created. Was just reviewing this prior to pushing a new version.

My idea here was to throw a message if we were able to detect a crash was about to happen, which is the most we can do. I implemented this today and realized that querying the actual open tabs causes the crash as well, so trying to detect a crash causes a crash.

End of the day, sublime is dying, stuff like this will never be fixed, so there is nothing that can be done.

[wbyoung]

It's been a while since I looked at this either, but just a thought after re-reading the conversation — what if you create the new file/tab before any threaded work and then updated the contents after the work completes?

I think this means the window would appear (and perhaps should have some loading message) immediately rather than once complete. But that could actually be nice.

[jonathanrdelgado]

That would work, but it would remove the functionality of having a single TodoReview tab.

Right now, when you use the command, it will do the following:

• Gets a list of all files
• If OpenFiles, gets a list of all (Causes a crash)
• Search
• Searches for existing TodoReview tabs to combine (Causes a crash)
• Renders

If we were to move the render to before the search, it would still cause a crash by searching for existing TodoReview tabs, since we want to combine them rather than make a new tab every time it is run.

Essentially, we need to look at tabs before both searching and rendering.

[wbyoung]

Ah, I see. Too bad.

Thanks for the update and trying to fix it!

[jonathanrdelgado]

Yeah, sad to see sublime is such a state of disarray. Thanks for your time!