Hi @SaurabhNair96 - sorry to hear you're having this issue. Can you return the exit code of Syft? (In the Ubuntu terminal, run echo $? immediately after Syft exits). I suspect it's being killed by an out-of-memory error, but the exit code would help.

Hi @willmurphyscode exit code is 137

Hi @willmurphyscode just to follow up on that, we also tried it on a similar virtual machine with a lot more space and it still showed the same problem. Does the exit code confirm that it is a space issue? Thanks!

Hi @SaurabhNair96, 137 looks like an out of memory killer - the operating system killed the process because the process was running the computer out of RAM. dmesg will tell you for sure.

Thanks for attaching the image! It does seem like this image uses an inordinate amount of RAM when being scanned. We'll take a look. Thanks.

From an initial look it seems that the run frequently gets stuck in the package.json parser function. It's as if there is an infinity sized file (from a little bit of added logs to help out):

[0179] DEBUG parsing package.json file iteration=245397 pkgs=245396
[0179] DEBUG parsing package.json file iteration=245398 pkgs=245397
[0179] DEBUG parsing package.json file iteration=245399 pkgs=245398
[0179] DEBUG parsing package.json file iteration=245400 pkgs=245399

I saw that /usr/local/lib/python3.6/dist-packages/jupyterlab/staging/package.json from the image tended to hit this case.

Some debugging shows it's continually finding the same package again and again: jupyterlab/[email protected] (here is the innocent package.json file)

After a few breakpoints, it seems like there could be a bug in the squashfs lib reader... I believe I saw that the underlying reader after reading the file contents reset the internal file pointer (curOffset) back to 0 without returning EOF.