BrunoBernardino
commented
1 year ago I'm also experiencing this after upgrading from 1.34.x to 1.36.0 (Kernel is 6.1.41, glibc is 2.37, distro is Manjaro), with tiny test suites (1-3 files, all with Deno.test()). The constant among these projects is the "does the server boot" test, which seems to be where the test fails with the segmentation fault:
import { assertEquals } from 'std/assert/assert_equals.ts';
import { abortController } from './main.ts';
const baseUrl = 'http://localhost:8000';
Deno.test({
name: 'HTTP Server',
fn: async () => {
let response = await fetch(`${baseUrl}/`);
assertEquals(response.status, 200);
let responseText = await response.text();
assertEquals(responseText.includes('Something'), true);
response = await fetch(`${baseUrl}/blah`);
assertEquals(response.status, 404);
responseText = await response.text();
assertEquals(responseText, 'Not found');
abortController.abort('Test finished');
},
sanitizeResources: false,
sanitizeOps: false,
});main.ts is pretty basic too:
import routes, { Route } from './routes.ts';
function handler(request: Request, connectionInfo: Deno.ServeHandlerInfo) {
const routeKeys = Object.keys(routes);
for (const routeKey of routeKeys) {
const route: Route = routes[routeKey];
const match = route.pattern.exec(request.url);
if (match) {
return route.handler(request, match, connectionInfo);
}
}
return new Response('Not found', {
status: 404,
});
}
export const abortController = new AbortController();
const PORT = Deno.env.get('PORT') || 8000;
Deno.serve({ port: PORT as number, signal: abortController.signal }, handler);Finally, routes.ts isn't, but can be pretty simple, to replicate:
export interface Route {
pattern: URLPattern;
handler: (
request: Request,
match: URLPatternResult,
connectionInfo: Deno.ServeHandlerInfo,
) => Response | Promise<Response>;
}
interface Routes {
[routeKey: string]: Route;
}
const routes: Routes = {
index: {
pattern: new URLPattern({ pathname: '/' }),
handler: () => {
return new Response('Something!');
},
},
};
export default routes;
I'm not getting segmentation faults all the time (it's like in 4 out of 5 runs), and in GH Actions I haven't seen it fail yet. Here's a "simple app" repo where this is happening: https://github.com/BrunoBernardino/deno-boilerplate-simple-website
lucab
bartlomieju
dsherret
marcosc90
tekul
I have a mildly large testsuite in a private repo, and after upgrading
denofrom 1.34.x to 1.35.x I'm starting to see segmentation faults. Specifically, 1.34.3 seems to be working fine while all newer releases up to 1.35.2 do segfault.I wasn't able to pin down what triggers the segfaults nor to get a minimal reproducer, but so far I've observed that they are easier to reach if I set up the test environment so that the testsuite fails quickly.
As a concrete example, the testsuite uses puppeteer against a local web app, and if I stop the local service then the test run used to fail in this way in 1.34.x:
Here above,
misc_test.tscontains some Deno tests and there is setup logic inutils.tsandgithub_signin.tswhich runs on import (and can fail, as seen).Under the same conditions, 1.35.x hits a segfault:
Stacktrace shows the following:
This on Linux kernel 5.19.0 and glibc 2.36 (stock Ubuntu 22.10).