I have been using the Macbook Pro M1 for web development for the past 7 months.
Lately, after about 1-2 minutes of starting my dev server (React with Vite and Gatsby), I get an ERR_NO_BUFFER_SPACE in Chrome, and I don't have an internet connection.
My co-workers with non-M1 Macbooks do not have the same issue.
So looking for this error in Chromium we get a reference to ENOBUFS in the source code here:
https://chromium.googlesource.com/chromium/src/+/HEAD/net/base/net_errors_posix.cc
According to this https://www.encyclo.co.uk/meaning-of-ENOBUFS the error is due to:
In programming, ENOBUFS is a POSIX error code defined in . This condition caused by lack of memory in the OS`s buffers. Typically occurs in socket programming
I would suspect that there's a bug in the socket programming in Chrome that is mostly manifested in the ARM version of the operating system. This could either be a Chrome bug or an OS bug.
In this message https://groups.google.com/g/nodejs/c/ahVUQHRVhAo?pli=1 it suggests that it could be caused by excessive writes. Could something in your React code be overloading a network buffer?
I had the same problem with my angular projects, but after closing visual studio the connection came back to normality. I uninstalled some extensions such as ninja log, WSL, html to jsx, etc. I could work normal again. I'm also using M1 Macbook Pro. I hope this can help you.
Related
I have written a JavaFX app running on Windows 10 machine in the office which has problems showing (painting/rendering) certain embedded controls such as a Pane with PdfBox when I connect to it with Remote Desktop for Mac. It shows only a black screen in the app instead of the pdf document.
When I connect using RDP from my Windows 10 machine at home to my Windows 10 machine at work, the app works just fine (the pdf is shown in the app).
I have the same problems using AnyDesk and Teamviewer.
The app only shows PDFs properly using a connection from Windows 10 to Windows 10 with Microsoft RDP.
It might be a JavaFX issue. Similar issues are described here (although not 100% identical):
https://bugs.openjdk.java.net/browse/JDK-8239589
https://bugs.openjdk.java.net/browse/JDK-8229394
However, since I guess Microsoft Remote Desktop for Mac is using the same technology as the Windows Desktop client, I would have expected it to work fine.
I have a Mac Mini M1 running the latest OS (Monterey) at the time of writing this post. I am also using the latest Remote Desktop client for Mac.
This problem is not new and was also present in older releases.
I have tried to play around with screen resolutions, both on Host and Client but nothing good came out of those tests.
Disabled also hardware acceleration in Remote Desktop for Mac preferences but it didn't change anything.
The machine at the office has the following specs (which I cannot change nor update)
Edizione Windows 10 Pro
Versione 20H2
Data installazione: 10/09/2021
Build sistema operativo 19042.1415
Esperienza Windows Feature Experience Pack 120.2212.3920.0
Anyone else who has seen this problem and perhaps resolved it?
Could it be a bug in either PdfBox or Remote Desktop for Mac?
Except for the above issue, the Remote Desktop Client for Mac is working great (not lagging as TeamViewer or AnyDesk) and the user experience is phenomenal.
PS: While this might be considered a programming question (since I wrote the app with JavaFX) but it might be better to post on another forum? If yes, which one? On the other hand, many similar posts (look at the suggested thread on the right) have been upvoted despite not dealing with programming issues.
Thanks.
How do you use PDFBox? I ask because this is not a JavaFX component. If you use a SwingNode for that it might be interesting to try one of my two PDFViewer demos here and see whether the problem persists.
https://github.com/mipastgt/JFXToolsAndDemos#awtimage
The difference is in how I do the rendering and maybe that makes a difference for your use-case too. But of course this is just a wild guess and I can't promise anything.
I tried to pull and tried to build two different bootstrap repos for Electron apps:
https://github.com/pastahito/electron-react-webpack
https://github.com/duskload/react-electron-webpack
Followed the instructions only to be getting this error while starting the app using npm start
AVDCreateGPUAccelerator: Error loading GPU renderer
I am using a Mac Pro with macOS Mojave 10.14.5. From what I read: Mac Pros (2013 model)'s GPU architecture stumbles Electron/Chromium [for reasons beyond me]. I do have Electron apps like Slack and Atom running on that machine without problems, but for some reason, it would appear building Electron apps is impossible on Mac Pro. I find that very odd.
Is there anything I can do to be able to develop/build Electron apps on a Mac Pro or is it the official stance of the Electron platform that no development can be done on Mac Pros?
Problems with the GPU acceleration and rendering can occur on Electron with misconfigured systems or driver issues. There are also other instances where these or similar issues occur, such as when executing Electron via a remote system, X11 forwarding or a remote desktop. In all these instances you will get some kind of GPU initialization error.
For the error you are experiencing, it is actually already covered briefly here on Stack Overflow (however they don't cover a solution);
electron error AVDCreateGPUAccelerator: Error loading GPU renderer
In my Electron applications I always have the following piece of code at the very begining of the application execution;
import { app } from "electron";
if (app.getGPUFeatureStatus().gpu_compositing.includes("disabled")) {
app.disableHardwareAcceleration();
}
This will check if the GPU supports hardware acceleration and disable it if this is not the case. This check is very important but is not executed by default in Electron for some inexplicable reason - which results in Electron failing to start (or rather open any window) on systems where acceleration is broken or unsupported.
If that doesn't work for you, simply calling (without the check)
import { app } from "electron";
app.disableHardwareAcceleration();
should do the trick - but you should obviously only do it temporarily during development and only if you really need to. The first block of code is the prefered method.
I am having trouble loading a game app on genymotion. The game is Star Wars Force Collection. I can load the game, get the splash screens, then it crashes.
I have done some research before I posted here. The possible problems found in the genymotion logcat file:
There was a line noting Google services was out of date, "Google Play services out of date. Requires 4030500 but found 3225136"
Fatal signal 11 (SIGSEGV) at 0x00000364 (code=1), thread 1796 (RefQueueWorker#)
W/NetworkManagementSocketTagger( 280): setKernelCountSet(10040, 1) failed with errno -1
Some have pointed out ARM Translator problem and OpenGL.
Then again I'm really not sure the problem, and I want to post the logcat file here but I don't know how to attach it.
For problem 1, I have seen other thread here that may have fixed it with code, I'm not savvy enough for that and my Google is not updating itself.
That's about it. A few details about genymotion and the VM. I am running the latest version of genymotion and virtualbox. I am using the downloaded Custom image 4.3 as provided by Genymotion. I flashed the ARM Translation v1.1. I flashed the Gapps onto it, (I tried a higher version of Gapps to try and solve the problem, but that just made it crash) and then Star Wars Force Collection, most up to date version.
Also, worth noting that the app was running fine for v2.++, until an update to v3.++ made the game crash. I updated my graphics drivers to try and mend any graphics issues.
So there it is, any suggestions will be appreciated.
I want to make a Windows store application using the monogame libraries, but for this purpose, I need to install Windows 8.1. The installation fails and gives me the error
0xC1900101 - 0x40017
This error is quite large and alot of people have had or still have it. I made alot of research on it and it seems that this problem is caused by driver incompatibility. I tried the installation about 15 times now, every time updating some drivers, installing updates, etc.
On the installation, it stops at 84% on "Applying PC parameters" step.
So I believe that the problem is that one of my drivers in incompatible and I need to remove it so here are my specs/peripherals:
ASUS G75VW qs71 laptop (16GB RAM, i7 ivy bridge) (I don't think it is the problem, since my friend has the same and it worked for him)
- Logitech G930 Gaming Headset
- Razer Orochi Mouse (Not the 2013, but the 2012)
If some of these drivers are incompatible, please tell me how to remove them.
Thank you.
P.S. I'm not sure if this question is relevant for this site, but it is somewhat programming related and I need it to do programmation.
I have had basic tests for meteor on a Windows7 PC.
But there the application crashed too often.
Before this, I tested meteor on PC running Windows8. There, crashes happened much less often and generally they were recovered when I shutdown and rebooted the meteor.
Is Meteor unstable on windows7?
Or is there any way to avoid this?
The version packaged to the MSI installer that can be found on win.meteor.com is not official. If you want a more stable, try the virtualized option I've described on the site. I've been using that for a month without issues.
Please could you be specific about what problems you are seeing, for example, what do you mean by 'crash'.
You can certainly raise issues on SO, but if they appear to be specific to the windows port, please raise a ticket at: https://github.com/sdarnell/meteor
The only difference between Win7 and Win8 meteor, is that the installer sets the Win7 compatibility mode for the node.exe executable on Windows 8.
There are also relatively few differences between the windows port of meteor and the official linux/mac release. So there is a possibility that the issue is either environmental (e.g. you have different things installed on the two machines), or it may even be a core issue that just happens to appear more often Win7 due to timing issues (there was a case of this in 0.6.3).