I just met another kernel panic.
My Environment :
MacBook Pro (13-inch, M1, 2020)
macOS Big Sur 11.2.1
Obsidian 11.4
I turned off the graph view in the Core plugin last week, I have never met any Kernel panic in the last five days. 
Unfortunately, it happened after I switched the theme from Minimal to Atom.
(In my own experience, the reboot usually happened in a few hours after I changed the theme. )
Just giving some information.
Thank you~
Did you have kernel panics with Minimal too?
I did at least
In my case, I didnât have the Kernel panics with âMinimalâ.
Actually, I used the âPisumâ theme and never changed the theme in the past few days and itâs fine.
Today, I used the âMinimalâ for 4~6 hours then switched to âAtomâ. (But I tried several different themes when I was switching the theme)
After a few hours, the kernel panic happened.
Donât forget to send the reports to Apple.
I donât use any theme, just CSS snippets, and one of them was from the Minimal theme.
I thought it was breaking the Preview pane when scrolling through lists but I could reproduce this with other themes too 
while just previewing themâŚ
There seem to be something wrong on that vault 
âŚ
As I created a new vault today, Iâm going to work on this new one and see what happens 
. Maybe Itâll help debug the vault in which I encountered Kernel panics .
Done, each time .
Is it useful to add a comment when sending the report ?
If yes, what should I say ? 
not much other than emphasize that itâs caused by an electron app.
Thank you @WhiteNoise 
!
Itâs basically what I did so far 
.
Is there any way to âsymbolicateâ these KPs to get a better idea of whatâs leading up to the panic? Itâs my (limited) understanding of kernel debugging that without this symbolication, the stack traces are basically worthless.
To be honest, if i could dig into the reports, I would do it just out of curiosity .
Looking on the web about kernel panics and falling into a very small rabbit hole, I ended up opening the Console on my Mac for the very first time 
.
In the system logs, Iâve found this :
Mar 2 18:53:08 NameOfMyMac Obsidian Helper (GPU)[5861]: getattrlist failed for /System/Library/Frameworks/OpenGL.framework/Resources//GLRendererFloat.bundle/GLRendererFloat: #2: No such file or directory
The time is basically when I opened Obsidian. No idea what it means though 
.
After 3 days without a kernel panic, I just got one this afternoon as I was working on a very new vault (reported to Apple).
As itâs a new vault (iCloud - 74 Ko - 50 files in 7 folders) it means that :
As for the Core plugins, everything is enabled except :
For the 3rd time though, the kernel panic happened while I was trying to copy/paste something from Chrome into a note in Obsidian.
I had 2 different notes opened side by side, both in Edit mode.
One was a list (some type of Index) and the other was a note concerning one of the items in the list. I was going back and forth (Cmd + Tab) between Obsidian and Chrome to complete my note copying and pasting what I needed.
I had done this for quite a few hours when, wanting to paste what I just copied from Chrome, I tried to place the cursor at the right place in my note but Obsidian froze (for few short seconds) and the kernel panic happened.
As for the rest :
Obsidian v0.11.3
macOS Big Sur Version 11.2.2
MacBook Pro (Retina, 15-inch, Mid 2014)
Processor 2,5 GHz Quad-Core Intel Core i7
Memory 16 Go 1600 MHz DDR3
Graphics Intel Iris Pro 1536 Mo
@Pch Your post rang a bell for me. I remember pretty clearly that my KPs also seemed to happen when copy/pasting. That could be an important clue! I havenât had a panic in a couple of weeks (knock wood) but I will keep a closer eye on this.
As per my previous post, I still think we are lost without the symbol (dSYM) files to be able to decode the crash dump. And weâre fooling ourselves if we expect Apple to help on this. Itâs going to have to be fixed by the Electron devs somehow.
It baffles me that such a low level crash occurs in such a high-level app like Obsidian. Especially since VSCode is also written in Electron, supports 1000x the amount of plugins, and is used my millions of people every dayâŚand seems to not suffer from this somehow. So strangeâŚ
VScode does suffer from the same problem
That could be a clue, yes (well, at least, it begins to gently look like some kind of pattern) .
But as Iâve just encountered another one few minutes ago (and reported it to Apple), I think the Obsidian Helper (Renderer) has troubles with the mouse (placement and rendering correctly the pointer) âŚ
Iâm saying this because of this very new kernel panic.
Same setup as yesterday (when the kernel panic happened) :
Edit ModeObsidian has been opened in the background for at least 2 hours without any problem (I was not actively working on it, just browsing the web while waking up) and I decided to check the graph before doing anything. I closed the graph and opened the note from yesterday (concerning one item in my âindexâ), to the left (as itâs the first one I opened) and then opened the âindexâ, therefore opening to the right.
As I like to have the âindexâ to the left, I was going to rearrange those 2 notes when once again, Obsidian froze and the kernel panic occurred with my pointer stuck right in the middle of the 2 notes.
Yesterday, while I was actively working on those 2 notes, copying and pasting things from Chrome into at least one of them, after doing this for a few hours before the kernel panic, the pointer had trouble to be rendered correctly, like it didnât know which form it should take: where it should have been the âselectorâ (the cursor looking like a big I) to select some text in my note (as I was already in the line), it was more often the âarrowâ or a âhandâ (and whatever the form it took, it still did what I wanted : selecting some text in my note)⌠The more I worked on that note, the more the cursor seemed unstable and the appropriate rendering of the cursor seemed to be delayed each time a little bit longer.
This morning, kind of the same thing happened: I tried to grab the top left corner of my âindexâ note (to drag it where I wanted it to be) but the cursor never rendered as the usual âhandâ : it stayed as an âarrowâ and I was already in the middle of my screen when I saw the pointer got stuck there and Obsidian was frozen âŚ
Now, if I look at the spin reports from the console, under Heaviest stack for the main thread of the target process there are things there about some event happening and my mouseâŚ
Yes, you seem to be on the lucky side and I wish I could say the same thing.
Whatâs weird though, is that those kernel panics came out from nowhere as I have been using Obsidian for few weeks before encountering my first oneâŚ
But thank you for keeping an eye on this ! Iâll keep my fingers crossed for you 
.
I feel kind of frustrated by all this 
. Iâm almost at the point where I hope, the kernel panics will just magically disappear , like they seemed to have appearedâŚ
As for the âsymbolicationâ I really donât have the knowledge (and the time) to go in that direction, sadly .
Iâm thinking of maybe reinstalling Obsidian 
. Maybe one of the its files got corrupted during one of kernel panic ?
Is it possible for Obsidian to disable the GPU from within its own code? A switch in the GUI to turn it off would be a lot easier than having to run it from Terminal each time. I run a bunch of critical VMs on my Mac, and I really canât have it going belly up with a random KP in the middle of the day.
I understand that this is over the heads of @Licat and @Silver but everyoneâs hot-potatoâing this thing. Electron devs wonât touch it and have closed the issues, and we donât have a snowballâs chance in hell of Apple paying attention to this.
So basically the options are
Are there any options Iâm missing here? I hope a better one presents itself.
Hmm. This might be relevant to your idea:
Seems like calling app.disableHardwareAcceleration() before the app is ready might be a way around this.
@luckman212 : This seems like a thoughtful compromise which I hope can to unblock the situation 
.
(A âband-aid solutionâ in this case is still way better than nothing while waiting for a real fix somewhere)
And I agree with the list of options left to us, users encountering kernel panics, sadly 
.
Iâve search for an appâ like Obsidian for years as itâs the first one to actually help me but mostly motivate me to write and unload my brain somewhere (this is literally one of my life goal, something I need to do, for the sake of my mental health).
I come from Bear (which I still partially use, while waiting for an Obsidian Mobile appâ) and it worked just fine for me but it never motivated me like Obsidian does. The graphâ view accomplish that magic trick and the rest of the appâ (multi-panes, customizable themes/CSS snippets) helps me to feel finally âHomeâ. (If I wasnât financially tied right now, I would support Obsidian eyes closed just for what Obsidian gives me).
So, yes, Iâm hoping something could be done for those kernel panics as I really donât want to back to my âold systemâ which didnât work anyway 
âŚ
After that, I realize we seem to be just a very small fringe of users experiencing those kernel panics and âwe donât always get what we wantâ but this thought is profoundly saddening me⌠So all I can do is hope, report the kernel panics, wait and see .
Sorry for the rant here .
Now, I once again run into a KP which I reported to Apple :
And this time :
Edit Mode (2 daily notes)Cmd + X) those lines and was going to type [^1] were they were when the KP happened.So, 4 times out of all my KPs, the KP occurred while having something in my clipboard.
But, opposed to the KPs occurring with the mouse troubles (delays, rendering of the pointer, lack of precision) Obsidian didnât freeze before the KP.
I looked into VSCode a bit and I found that they definitely support disabling GPU programmatically via the app. Itâs a hidden feature. But if you go to the command palette (cmd+shift+P) and type runtime
you will get to a hidden argv.json config file
In there, you can uncomment that "disable-hardware-acceleration": true line to permanently disable GPU rendering. Hopefully Obsidian can add a feature like this to help us until (if) the root issue can be fixed by Apple.
Some more research:
Most comments from the Electron dev team point the finger at this being a Chromium bug (upstream of the upstream lol). So the embedded Chromium version seems important. Obsidian 0.11.5 looks like itâs using Electron 11.3.0 which is based on Chromium 87, so there could be some significant fixes there.
/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" '/Applications/Obsidian.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/Info.plist'
11.3.0
Electron v12 (based on Chromium 89) was released 3/2/21 - electronjs.org/blog/electron-12-0
Not sure how difficult it would be to produce a build of Obsidian with v12 but @Licat @Silver could this be done as a private build so the users suffering KPs could test & report back?
Random crash/KP reports indicate that some versions are definitely more prone to crashing than others:
this comment says âElectron 9.3.5 is okâ
this comment says âno crashes under v8â
this comment says âcrashes on 11.2, works fine under 11.1â
We will swich to electron 12 in the next weeks.
We might even add a switch for turning off gpu accelleration.
I have read enough reports to realize that nobody has figured out what is going on.