TypeError: Cannot read properties of undefined (reading '0') in devContainersSpecCLI.js for some features #699
Comments
|
Thank you for cross posting this issue in the feature repo. I hope they will be able to provide clear directions specific to this feature. |
|
The error is in the tar module which we recently updated. Does this reproduce with the CLI version 0.53.0? |
chrmarti
added
bug
I'm not very good at TypeScript debugging. But next I'll try cloning this repo and see if I can convince it to run with no minify so I can at least see the actual line of code having this issue. |
|
|
Looks like paths usually have items pointing at CHECKFS2: But with a debugger, I can see that during the crash, paths have 2 elements. Both with a value of "undefined". I checked that reserve() never insert invalid elements. So the function must have become undefined after getting inserted. I don't know enough about TypeScript to understand what's going on or why it's only triggered by this one particular repo. But I'll be happy to test things out if you have any ideas. |
Not sure this is the correct unminified code, the minified code is using Could you install version 0.53.0 of the CLI (e.g., |
I missed that you were running the unminified code. The error seems to be specific to the |
|
0.53.0 gives exactly same result as 0.54.2 and main branch on git: |
No, that's not the unminifed code. The unminified code is in the previous comment: It does use every(). I was saying that in the unminified code, I can see with a debugger that paths initially have valid elements and q[0] is valid. But after a few loops, paths is an array with 2 undefined elements. [undefined, undefined] When we do every() on it, q === undefined and therefore q[0] is not a valid statement. That's why we hit the error. I then tried to see who put the undefined in there. There's only one place we touch that field in the entire file that I can find: CHECKFS2 is a local function. We put a pointer to it. It's not possibly to have undefined. The function also prints that out on console so I can verify it: fn is always defined. Something weird is going on there. |
|
Did some more debugging. At the time of the crash, queue has 3 elements: The first 2 are for the dir case. The last for the path case. This is how we get the paths and dirs: Looking thru |
|
Wait a sec. We added this entry in the beginning: The same path is duplicated. When we're done, we call |
|
The tarball contains a hard link to itself for that file because some implementations of tar does not de-duplicate files specified multiple times indirectly thru parent directories. This happens if a file is specified multiple times indirectly by the directory when it is created. libarchive/libarchive#1381 (comment) Apparently both GNU tar and libarchive just ignore this kind of silly links instead of fixing the problem. It's stupid but might want to do the same for compatibility. |
chrmarti
added
upstream
This works around a bug where tar files could be generated with two different instances of the same file, which in turn tickles a crashing bug in the container builder (devcontainers/cli#699). This is the same solution as in devcontainers-community/features-llvm#7 and devcontainers-community/features-bazel#13. Closes devcontainers-community#3
For some reasons, this feature causes devcontainers to choke:
build.log
3.0, 3, and latest gives same problem. But cloning the repo and refer to it locally works.
It's not clear what the problem is or how to even begin to debug this problem with the minified script. Do you guys offer a debug build somewhere?
The text was updated successfully, but these errors were encountered: