Atom crashed and my source file ended up blank


#104

i just registered here to say that after a pc crash all my tabs are gone today. all my work, and i wasnt be able to restore them. i really hate your editor now. you ruined my life


#105

It just happened to me too… I saw 2016 posts that you are working on this, but you didn’t fix this. WTF. This is the worst thing that could happen . To lose all your work … You should have fixed this…


#106

It happened also to me twice. The first time Atom crashed and I’ve completely lost my 40 minutes slides the night before the presentation. Now, without ANY reason I’ve found my PhD thesis tex file completely empty. It was on Dropbox and I’m not even able to restore the previous versions of the document. I think it is better if you focus your efforts on something else instead of losing your and our time on something you are evidently not able on. Atom has no reliability at all.


#107

I’ve just had this happen as well. My Mac crashed and when it came back all of my open tabs had been blanked leaving 0 byte files. The interesting bit is that the file write time doesn’t seem to correspond to when the Mac crashed, but instead to the actual last time I wrote the files.

Please let me know if there’s anything I can do to help further troubleshoot.

$ atom --version
Atom : 1.33.0
Electron: 2.0.11
Chrome : 61.0.3163.100
Node : 8.9.3


#108

I just experience it today. :disappointed_relieved: i really like atom but this kind of issue is not very good for editors. I’m think to swith to different text editor.


#109

It just happened to me too.
I wont use Atom anymore.
:triumph::triumph::triumph:


#110

I’ve been able to get hold of crash logs for this happening in current and recent versions on Mac OS. Maybe someone can understand them. It looks like some kind of segfault (yay).

This is an ongoing problem that’s been happening for months. I’ve tried removing lots of plugins and gradually adding them in again, but the bug is so intermittent/random that it’s not a viable approach. It just happens in the middle of normal use. It might be to do with linting or switching away to another window, but I wouldn’t bank on either.

It doesn’t give a useful error, it just comes up with some kind of “The editor has crashed” error and offers to close or reload the window. Picking either option results in an empty source file. The source file is already empty before clicking either option (checked with git).


I hope this helps someone investigate what’s going wrong.


#111

Realy Dude… My File just Blank.!!! no one using atom anymore… bye.


#112

Yup, just happened to me last night. I can’t believe after three years this issue still persists. Going back to brackets!!


#113

It’s been quiet for a little while then happened 3 times in quick succession today. After turning linting off, so it’s not the linter addons.

I’ve started using the local version history addon to recover files, but going to switch to another editor soon because if I wanted my work randomly deleting I’d get a cat.



Does anyone have similar Mac crash logs (open console.app, look at “User Reports”, right-click show in finder), or ones for another platform?


#114

From your crash logs, it looks like the underlying Git utility libgit2 is crashing.

Thread 0 Crashed:: CrRendererMain  Dispatch queue: com.apple.main-thread
0   git.node                      	0x000000010f4f392f hash__block + 174
1   git.node                      	0x000000010f4f383f git_hash_update + 143
2   git.node                      	0x000000010f4a4549 git_hash_vec + 76
3   git.node                      	0x000000010f4b99d9 git_odb__hashobj + 129
4   git.node                      	0x000000010f4b9cab git_odb_hash + 35
5   git.node                      	0x000000010f498d19 git_diff_file_content__load + 1101
6   git.node                      	0x000000010f499339 diff_patch_load + 228
7   git.node                      	0x000000010f4995c4 diff_patch_generate + 91
8   git.node                      	0x000000010f499ea9 git_patch_from_diff + 448
9   git.node                      	0x000000010f47917e Repository::GetDiffStats(Nan::FunctionCallbackInfo<v8::Value> const&) + 550
10  git.node                      	0x000000010f47d1e1 Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) + 136

I don’t think this is the same issue as I was able to reproduce, as I wasn’t in a Git repo.

Still,

happened 3 times in quick succession today

@nruth Was this right after opening the same specific file each time? Was there a delay in seconds / minutes / hours? Do you have anything in your .gitattributes file? (this was brought up in a closed libgit2 bug about crashing; it may be relevant). Do you know if you’ve done anything “weird” to your git installation?

And could you raise this as an issue on the Atom repo where people who know more about this than me can look into it.

Thanks


#115

Thanks for looking at that. Too bad it’s not connected in some grand bug that solves everything, but at least it gives me a clue what’s happening to me.

Unfortunately I can’t see how to turn the git features off. I’ve already got the Git Diff package disabled so I don’t know why it’s even running that code.

I don’t have any git customisations except setting a name and email address.

git version 2.17.2 (Apple Git-113).

I’ll open an issue at some point.


#116

Yeah, I thought it might be the git diff package too, but the actual git repo set up is tied with core. I got to this function here (matches the initial C++ function name), which could have been called by anything.