Feb 22, 04:57:05 PM: RequestId: 652c6b54-8d04-424c-ad7b-d66bebd47569 Error: Runtime exited with error: signal: segmentation fault
Runtime.ExitError
After some quick tests, I discovered that if I go directly to another page’s URL (csr/ssr), the error doesn’t happen again, even if I go back to the homepage, which really isn’t a solution but maybe might be helpful.
Hi @arndom, since the suggestions did not work, usually this is a type of out-of-memory error for the lambda function.
We don’t have any special way to gain insight into what a deployed function is doing. There is no “internal-to-Netlify” profiler or other way to see the internals of a function invocation.
For this reason, kindly add console.log() and console.time() calls to the code responsible for this route to reveal more about what the code is doing when the segmentation fault occurs.
Doing so may be the best way to reveal the cause of the segmentation fault.
It’s a index.astro file that is server-side rendered. I can’t figure out where to put the logging calls that would show the error triggered by the lambda when attempting to render the page.
Hi @arndom, thanks for trying out the suggestions.
At this point, the best you can do is turn off server-side rendering if you are not using it to see if it will help resolve the issue. I also suggest you take the time to go through your build logs to see if there is any indication that might be causing the error.
To turn off server-side rendering in Astro, you need to change the output configuration in your astro.config.mjs file. Here’s how you can do it:
Open your astro.config.mjs file.
Look for the output property.
Set the output value to "static" instead of "server" or "hybrid".
Here’s an example of how your configuration should look:
import { defineConfig } from "astro/config";
export default defineConfig({
output: "static",
// other configuration options...
});
By setting output to "static", you’re telling Astro to generate static HTML files at build time instead of rendering pages on the server.
It’s important to note that turning off server-side rendering will disable any server-side features you might be using, such as dynamic routes or server-side API endpoints. Make sure your site doesn’t rely on any server-side functionality before making this change.
I resolved it by converting the dynamic component to a server island rather than opting for server-side rendering for the whole page. This handled the suspected out-of-memory lambda function.