Async stack trace stitching
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- c, javascript
- Área
- compilers
Línea de trabajo
Reproduce the two async examples shown in test_ex3.js and compare their stack traces. Then inspect JSJobEntry and the pending-job execution path; done means errors after await retain the async caller frames, with any DEBUG_PRESERVE_ASYNC_STACKS behavior covered by tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
When you call await in async functions, it truncates the stack trace on errors.
For example, this:
async function a() {
await b();
}
async function b() {
await 1;
throw Error("poof");
}
a().catch((ex) => {
console.error(ex);
});
will result in a stack trace like this:
Error: poof
at b (test_ex3.js:8:16)
But when we remove the await 1; statement we get the full stack:
Error: poof
at b (test_ex3.js:8:16)
at a (test_ex3.js:3:12)
at <eval> (test_ex3.js:11:2)
Could async stack capture be built into QuickJS? For example, by copying the current stack to JSJobEntry when scheduling and then restoring the stack when executing pending jobs. Perhaps this could be enabled only when a DEBUG_PRESERVE_ASYNC_STACKS flag is set.
For reference:
Spidermonkey only does it when debugger tools are open: https://bugzilla.mozilla.org/show_bug.cgi?id=1601179
V8 has a more elaborate solution http://bit.ly/v8-zero-cost-async-stack-traces
- Lenguaje dominante
- C
- Estrellas
- 11.1k
- Forks
- 1.2k
- Merge medio
- 11 h 20 min
- PR fusionados (30 d)
- 1
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de bellard/quickjs
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 3 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 3 días
-
Collecting WeakMap keys requires multiple GC passesPosiblemente ocupada @jluxenberg la tomó hace 2 días. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
bellard/quickjs#581 · 1 comentario ·
Los mantenedores suelen responder en 3 días
Todos los issues de bellard/quickjs
Issues similares
-
vim.filetype.match() prefixes a URL buffer name with the cwd before passing it to filetype functionsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
compilation errorAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
COVESA/dlt-daemon#925 · 1 reacción ·
-
stream_curl: retry_count never resets after a successful reconnect, so long sequential streams die after 5 dropsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
mpv-player/mpv#18728 ·
Los mantenedores suelen responder en 1 día
-
followup Prio 📌
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
cyrusimap/cyrus-imapd#6640 ·
Los mantenedores suelen responder en 2 días