v. 1.0.0 (48) is locking up and freezing a lot
Completed
Trying to use for note taking but is almost unusable. Have to force quit a lot. Nothing in particular seems to trigger this.
-
I'm experiencing the same and haven't found a resolution beyond force quitting and re-opening.
It doesn't become symptomatic for me when just browsing notes, just:
* sporadically while typing, copy and pasting – cursor disappears and the editor is locked up.
* almost every time I select a different file from the File List
No change after clearing Indexing cache.
0 -
Exactly the same here. Browsing is no problem. It happens when I type. Maybe (only maybe) scrolling after typing.
0 -
Seems to be resolved here since Build 49 today :-D
0 -
Michael Barton -- did build 49 resolve this for you as well?
0 -
I have just tried build 49 last night (on MacBook with Mac Catalina) and today on iMac with Mohave. It seemed to work without freezing on Catalina, but scrolling lagged a lot. On Mojave, it is as bad as before. I can only type a few minutes before it locks up completely. Both machines have a lot of RAM and fast processors.
0 -
Michael Barton -- do you have Xcode installed on your machines? I'm testing a means by which you could send me useful information about what is taking so long on your machines.
Thanks!
0 -
I do have Xcode
0 -
A question. I work across 3 locations (office, lab, home) with 3 computers (2 iMacs and a MacBook). My notes file is in dropbox. I try to remember to shut down nvAlt on each machine when I'm done, but could have forgotten and left it up on one. Would that have any impact? The computers I'm using have gone to 'sleep' of course.
0 -
I'll need to test that a bit. Early on in development I primarily used dropbox as my repo, without problems. I have since moved to predominantly iCloud.
If the computers are truly asleep, they definitely should not have an effect. And even if they are awake, because of the way I handle file interactions, it should not have an effect like this either (nvUltra works with the file system, and separately the Dropbox app handles sync back and forth to their servers.
If you follow these instructions, you can create a profile of which sections of code are running when you notice the bog down:
https://gist.github.com/loderunner/36724cc9ee8db66db305#profiling-with-instruments
Just try to type for the 30 seconds or so, and it will save a file that you can then send to me to try and extract useful information from. It should at least tell me where to start looking.
Thanks!!
0 -
Did it. Here is the message. How do you want me to give you the file (28Mb)?
TCLASHE-C02Q40UVFY14:~ cmbarton$ instruments -l 30000 -t Time\ Profiler -p 83730
CoreData: annotation: Failed to load optimized model at path '/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/Frameworks/InstrumentsPackaging.framework/Versions/A/Resources/XRPackageModel.momd/XRPackageModel 9.0.omo'
Instruments Trace Complete: /Users/cmbarton/instrumentscli0.trace
0 -
Yeah -- I'll need the file to be able to see where the app is spending it's time. Probably too large to email or attach here. Can you do a dropbox link or something like that? You can email that to me or send via support ticket if that is better for you than posting in the forums.
admin at multimarkdown.com
Thanks!
0 -
For anyone else with similar problems, the same approach will be useful to get my actionable data. The main thing is to make sure that the sampling is done *while* nvUltra is being sluggish so that I can see exactly what the CPU is spending its time doing.
Thanks!!
0 -
In the sample you sent, it's spending 91% of the CPU time updating the index. You probably sampled right after opening a new window?
Main thing is that this was a good proof of concept test that this is a useful way to see what is happening on your computer (I've never tried this before -- only used the profiler on my own machine with available source code.)
When nvUltra gets sluggish on your machine, try this again and send me the report. It should help me figure out what is happening.
Thanks!
0 -
Michael Barton et al -- when you switch back to nvUltra and it locks, are you working on a file that is also open in another application?
I have been looking into what I thought was a separate issue (editing a TaskPaper file in nvUltra and TaskPaper at the same time). By coincidence I was doing that today, and happened to move on to other work. When I tried to activate nvUltra again, it would not respond. Activity Monitor showed that it was not responding. Running the instruments step described here (https://multimarkdown.zendesk.com/hc/en-us/community/posts/360039250034-How-to-properly-report-a-bug) resulted in an empty stack trace (similar to what Michael sent me). Running the `sample` approach described here (https://gist.github.com/loderunner/36724cc9ee8db66db305#profiling-with-instruments) however, showed that it was locked waiting on read access to a file. (Which is the same problem I had with TaskPaper previously.)
Killing TaskPaper resulted in nvUltra immediately starting to work again.
0 -
I have just wrapped up a major project at my day job, and am hoping to dive into the few outstanding known issues with nvUltra tomorrow. Any further information anyone else can come up with for this would be great! Thanks!!
0 -
Just installed 1.0.0 (50) and tried to lock it up. Unfortunately, I succeeded. I went to a note that I don't have open anywhere else. Then I random typed the following very fast, with some copy/paste and cut/paste. The lock up happened shortly after the cut/paste but that could be random. I include the gibberish below to give you an idea of how much typing happens before it locks up. This seems pretty average for my experience over the past couple weeks. When I tried to do a trace after if locked up you said it came back with nothing. I might be able to do a trace for a longer time interval to lock up while I am doing it.
Anyway, here is the random text:
fpaeoiruospifnjaoeprusdifjapofuadil;fjapoefsodifuapofupado8ufapodifuaopufoipufaeiopufa
jcadpfuysaeioruaepofuasdiopfuasdofuaepofuapsoureoifupearufaosipufaopisufapoesiufsoidfuasoifuaoifupdoifuspifuasopiupeoiufopidfuosfiuadpoisfjadphfifu98er809-r7-0[9fupaiue9-4r87doijfapo8updr8ru[aos9pufp9weufdp8ruo9ifhadposfjdkfs;kfasdhflakhfakhf]]## adfpoisadruase98rp89ua98EF7UP98RUEWAF fjadioufpaoiduffjadioufpaoiduffjadioufpaoiduffjadioufpaoiduffjadioufpaoiduf
fjadioufpaoidufgsdfg[osdfig[poirti0[er[pocmv'dops[]]]]] adfadsfdrae aeraeweopirupeoirtupoeijcDO:Ifuaepoifupaeurpoisdjfpao8esufomkj;iusdofipuasdfiop
fjadioufpaoiduffjadioufpaoiduffjadioufpaoiduf
here sisdifja;fjadioufpaoiduf jajaoifuasdiouoiufoiadupoaisduoiupoiuouoiuoijennenne doapfoisoueoaiuiounn poasdufpoiadufpaoisufopaiufsdfjapdfu
adhfpeisurpoiwerupoweuro;isjpaesuroi;sdufopadsufpaeourpew9urpeowufpaosidfa89seurpoiaseufaeosufaspoidfjadpfoauewroiupepoiruopquqewp89ruqwep9fuas;lkdfihapse8ruawpe987sdpofuer98apfp98e7rp98se7r0a9e7f0a9se7r90ae7r
fasfraeurqpwe8r70qwe98r70970 -
Thanks -- trying to dig into this with a couple of different approaches. One might be leading somewhere productive.
More to follow.
0 -
I created an AppleScript to stress the app. It "types" at almost 1000 wpm (clearly much faster than I can type with any pretense of accuracy.).
On my machine, nvUltra handles it no problem. (The rapid updates on longer paragraphs do cause the statistics bar and the preview to stop updating until it can "catch its breath", but the text editor view itself continues to update with each character typed. I have yet to see any skipped characters.)
I wondered whether saving the file might be part of the problem. So In stress tested further by turning undo coalescing off, and reopening the folder. That forces a save after every character typed. No problems.
One thing I find was an issue where nvUltra could lock when reactivating via the global shortcut, *if* there was a mismatch between macOS and MMD tags on the active file, and nvUltra is set to automatically synchronize those tags. That should not have an effect when typing and the app remains in the foreground, however.
0 -
Another tact, since I have yet to find an answer -- if you're experiencing this, can you send the output from `defaults read com.multimarkdown.nvultra` to us as a support ticket. The only personnel information that is really in there is path information about folders and files that you have used. If that concerns you, you can delete those lines before sending.
Maybe this will point towards a way to replicate the problem...
Thanks!
0 -
FWIW, I also experience the lock-up (spinning beach ball) on version 1.00 (52) as I did while using a couple of prior versions.
While I know nothing about Xcode, I can report that this freezing/unresponsive state happens regularly when I am copying and pasting from Safari (v. 13.05) on my 16" MacBook Pro with more than 20 gigs of RAM available.
I hope you can find the culprit as NVUltra Beta has unfortunately become nearly unusable for me while attempting to enter new information.
Thank you for all you are doing.
Don
0 -
Michael says that recent builds, e.g. 58, have not demonstrated this issue.
Is anyone else still experiencing an issue like this?
Thank you,
Fletcher
0 -
Since Build 58, all has been stable. Thanks for checking.
Don
0 -
Thanks. I'm going to close this one out. If anyone experiences something similar, please open a new issue.
Thanks!!
0
Please sign in to leave a comment.
Comments
23 comments