CodeSandBox core dump investigation

[divyenduz]

When starting a CSB with Photon, it sometimes yields an error like this

Example: https://codesandbox.io/s/prisma-3zk19

This project has a "core" (core dump) file in prisma/ folder that is not visible in the UI because it is too large to be synced for CSB (as of today).

To get a hold of this file, run python -m SimpleHTTPServer in the CSB shell, then use the "Server Control Panel" "Open ports" to download it to your file system.

Running it through gdb -c core yields

For help, type "help".
Type "apropos word" to search for commands related to "word".
[New process 206]
[New process 205]
[New process 207]
[New process 199]
[New process 202]
[New process 203]
[New process 198]
[New process 200]
[New process 204]
[New process 201]

warning: Unexpected size of section `.reg/206' in core file.

warning: wrong size gregset struct in core file

warning: Unexpected size of section `.reg2/206' in core file.
Core was generated by `/sandbox/node_modules/@generated/photon/runtime/query-engine-linux-glibc-libssl'.
Program terminated with signal SIGILL, Illegal instruction.

warning: Unexpected size of section `.reg/206' in core file.

warning: wrong size gregset struct in core file

warning: Unexpected size of section `.reg2/206' in core file.
#0  <unavailable> in ?? ()
[Current thread is 1 (process 206)]

Interestingly, this happens when CSB is loading, once it is loaded, photon queries work and most query engine operations (I tried them by manually calling the engine with environment variables) work.

Also, Core was generated by /sandbox/node_modules/@generated/photon/runtime/query-engine-linux-glibc-libssl'.form the logs is different from the actual binary path which is named differently asquery-engine-linux-glibc-libssl1.1.0` (I think it is renamed and that might be related)

Notes (when inside gdb prompt):

Load the symbols:

symbol-file <binary-path>
sharedlibrary

Stacktrace: bt
Stacktrace for every thread: thread apply all bt full (output: https://gist.github.com/divyenduz/dfa1c2cc684b016a84b483c784c58449)

---

Core dump file: https://divyendu.s3-eu-west-1.amazonaws.com/core
Binary that produced this: https://divyendu.s3-eu-west-1.amazonaws.com/query-engine-linux-glibc-libssl1.1.0
CSB repro (flaky): https://codesandbox.io/s/prisma-3zk19

[divyenduz]

Next steps: Try to reproduce this locally by trying to create CSB environment. It is k8s + docker image based on node:10.16.0-stretch.

Unconfirmed, that the filesystem might be lazily mounting (maybe a SO linking error happens initially).

Next steps: try to reproduce this with a debug binary.

[divyenduz]

Context:

[divyenduz]

This is not reproducible anymore with prisma2@2.0.0-preview016.2, binary version: b72fd0a786adc77ba6c61d0a9637ff0371e433b0

Created a fork (to still preserve the original reproduction) of my reproduction CSB here: https://codesandbox.io/s/prisma2-core-dump-j3t1z

Closing this issue for now, please re-open (or comment on this issue and tag me) if you see this issue again.

Underlying (hunch) issue: https://github.com/jgallagher/rusqlite/issues/583
Quoting Tom: "The workaround on our side was to just not send empty queries"