Crash Report

[Eniiqz]

[ERROR] Rojo crashed! [ERROR] This is probably a Rojo bug. [ERROR] [ERROR] Please consider filing an issue: https://github.com/rojo-rbx/rojo/issues [ERROR] [ERROR] Details: called Result::unwrap() on an Err value: Io(Os { code: 9, kind: Other, message: "Bad file descriptor" }) [ERROR] in file memofs/src/std_backend.rs on line 21 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.

Got this error when trying to start a Rojo server in VS Code.

[LPGhatguy]

Thank you for filing an issue!

That is... a very strange error. I'm not sure if there's much we can do. What can you tell us about your system? What operating system, any sort of interesting storage? I've never seen this error before!

[jonnyunderwater]

I'm getting the same error:

I'm on MacOS. Installed everything yesterday and had it working.

To repeat issue, from GitHub Desktop I open my Branch in VSCode. Start Rojo serve in Terminal, I open a new baseplate (or a even one of our old builds) in Roblox Studio, use the plugin to connect Rojo plugin to the server...all looks good so far. And then I go into VSCode and select "Start Rojo" and ...

WARN ] Unknown value type name "OptionalCoordinateFrame" in Roblox XML model file. Found in property Model.WorldPivotData. [INFO ] Unknown binary chunk name SSTR [ERROR] Rojo crashed! [ERROR] This is probably a Rojo bug. [ERROR] [ERROR] Please consider filing an issue: https://github.com/rojo-rbx/rojo/issues [ERROR] [ERROR] Details: called Result::unwrap() on an Err value: InvalidTypeError(28) [ERROR] in file /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/rbx_binary-0.5.0/src/deserializer.rs on line 270 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.

When using the baseplate template and I go into Roblox Studio, it looks like it started to do the work. There's the first script in "ServerScriptStorage" and a folder and ModuleScript in one of our folders in "Replicated Storage"

Any thoughts?

Jon

[LPGhatguy]

@jonnyunderwater This is not the same bug. The report here is about a "bad file descriptor" error, while yours is something unrelated.

If you're using Rojo 6.x, you cannot use rbxm model files, you need to use rbxmx files instead. Once 7.0 reaches stable, so will rbxm files.

[Hexcede]

@LPGhatguy

Experiencing this on Linux, specifically Kubuntu 21.04, with Rojo 6.2.0:

[ERROR] Rojo crashed!
[ERROR] This is probably a Rojo bug.
[ERROR] 
[ERROR] Please consider filing an issue: https://github.com/rojo-rbx/rojo/issues
[ERROR] 
[ERROR] Details: called `Result::unwrap()` on an `Err` value: Io(Os { code: 9, kind: Other, message: "Bad file descriptor" })
[ERROR] in file /home/hexcede/.cargo/registry/src/github.com-1ecc6299db9ec823/memofs-0.1.3/src/std_backend.rs on line 21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

This occurs when executing rojo build, rojo serve, etc. Anything which tries to access the project file appears to be effected. It sounds like somewhere a file read is occurring and that file read is failing for some reason, and then later, the result of that error is getting mixed up in whatever that package is. Seems like an issue with cross-platform, maybe a Windows path is getting used or something? I'm not sure, I am just speculating.

This is the affected code:

The way that I produced this is by installing rojo through cargo, with cargo install rojo and then using the compiled binary, e.g. rojo build. You can see below that the cargo install is the binary getting used:

If I can find something in the source that looks out of place I will be sure to reply.

[Hexcede]

By running with RUST_LOG set to trace I was able to produce the following:

I believe the common factor between all of the commands is the line looking like this: ServeSession::new(vfs, &options.absolute_project())?;

Edit: Indeed, the following trace isn't being reached

Edit 2: I think the culprit is ServeSession, or perhaps the vfs stuff. https://github.com/rojo-rbx/rojo/blob/v6.x/src/cli/mod.rs has some noteworthy content too:

I tried both a relative and absolute path to both a json file and the project folder and got the same error still. Additionally, unlike with the above two commands, the init command works and properly identifies the path, yet it shares the absolute_path call, so, it must be something under ServeSession::new or Vfs::new_default()

Edit 3: Vfs is imported from memofs in build.rs, which is exactly where the error is from. This is most definitely the culprit.

[Kampfkarren]

Important to note that Rojo is not officially supported on Linux.

[Hexcede]

Important to note that Rojo is not officially supported on Linux.

I assumed that it was since there are Linux builds in the releases section and such. Is it really not supported?

[Kampfkarren]

Odd, it might just be a personal recommendation from the maintainers to use Windows instead then.

[LPGhatguy]

Important to note that Rojo is not officially supported on Linux.

Huh? No, Rojo is definitely officially supported on Linux. It's WSL that I push people away from because there is a Windows native build.

@Hexcede Can you print out some of the paths that are around? Some of your screenshots are just from imports. We don't have any platform-specific code or file paths here, but narrowing this down would help a lot.

[Kampfkarren]

It's WSL that I push people away from because there is a Windows native build.

Oh, my bad!

[Hexcede]

Important to note that Rojo is not officially supported on Linux.

Huh? No, Rojo is definitely officially supported on Linux. It's WSL that I push people away from because there is a Windows native build.

@Hexcede Can you print out some of the paths that are around? Some of your screenshots are just from imports. We don't have any platform-specific code or file paths here, but narrowing this down would help a lot.

I don't quite understand, but, there's more info in my second post. So far, I've narrowed the source of the error down to line 45 of the following file through inspecting the trace logs: https://github.com/rojo-rbx/rojo/blob/v6.x/src/cli/build.rs I believe line 22 of the following file is also producing this error: https://github.com/rojo-rbx/rojo/blob/v6.x/src/cli/serve.rs

In other words, the error appears to be originating from the memofs package when creating a virtual filesystem:

let vfs = Vfs::new_default();

That means that this error technically isn't caused by Rojo, but, I am unable to find any location to report the problem.

[LPGhatguy]

The crash report mentions enabling a backtrace. If you can run with RUST_BACKTRACE=1, it'll contain more details.

If you would capture the full stack trace and upload it as text, that would help track the exact line number. I don't think Vfs::new_default() does a whole lot. memofs lives in this repository too, but just calls out to notify.

[Hexcede]

The crash report mentions enabling a backtrace. If you can run with RUST_BACKTRACE=1, it'll contain more details.

If you would capture the full stack trace and upload it as text, that would help track the exact line number. I don't think Vfs::new_default() does a whole lot. memofs lives in this repository too, but just calls out to notify.

I looked at Vfs::new_default() and assumed it was the only place the issue could originate but I looked again and realized there's still several other lines which could be causing this, all entering into the memofs package as well. I might try and diagnose the issue by doing a custom build and see if I can locate the error, if I do I'll definitely post back.

I ended up running with RUST_BACKTRACE=1 before, but it doesn't provide any helpful information since the origin of the actual error itself is just somewhere within the memofs package, getting thrown from within some event queue or thread queue or something.

Here's the full output with RUST_BACKTRACE=1:

It doesn't provide anything useful, at least, I don't think it does.

I used RUST_LOG=trace to view several logs that Rojo outputs to help locate the actual position of the error which is being eventually thrown by something which I determined to be within lines 45 and 48 of the build script under the 6.x branch, and lines 98 through 99 in the file where ServeSession is defined.

Here are the two files respectively: https://github.com/rojo-rbx/rojo/blob/v6.x/src/cli/build.rs https://github.com/rojo-rbx/rojo/blob/v6.x/src/serve_session.rs

Here's the output with RUST_LOG=trace as well so you can see what I'm referring to:

This helped me determine how far the script is running up to to find the source of the error since (referring to the build.rs file I linked above) there are more trace logs created by ServeSession::new. Since options.absolute_project is also used by the init command and doesn't trigger a crash, that code path can be ruled out.

Here are what said logs look like in the code:

And, once again, this is happening for every command which tries to access the project at all (build, serve, upload) excluding init which works as intended, despite sharing a lot of code between eachother.

[KazabiteBoltiz]

Having the same problem!