paranoid cause full path in stacktrace

[obi458]

I always see my full path in stacktraces and crashes like
crasher:
.....
exception exit: {timeout,[{.....
[{file,"/users/james/bond/very/secret.erl"},{line,85}]}]}
...

now goes to

crasher:
.....
exception exit: {timeout,[{.....
[{file,"secret.erl"},{line,85}]}]}
...

cause we have a flat erl file structure it doesn't matter!

[ferd]

I don't think that this is a safe thing to do. Rebar3 may be running in shell mode for example, and changing the path can interrupt a running system with concurrent tasks going on.

It would be safer to make the source path relative ({source,FileName} option to the compiler) than changing directories, for example, based on configuration variables that already exist in rebar3.

[ferd]

See

rebar3/src/rebar_dir.erl

Lines 348 to 362 in 94976d5

	format_source_file_name(Path, Opts) ->
	Type = case rebar_opts:get(Opts, compiler_source_format,
	?DEFAULT_COMPILER_SOURCE_FORMAT) of
	V when V == absolute; V == relative; V == build ->
	V;
	Other ->
	warn_source_format_once(Other)
	end,
	case Type of
	absolute -> resolve_linked_source(Path);
	build -> Path;
	relative ->
	Cwd = rebar_dir:get_cwd(),
	rebar_dir:make_relative_path(resolve_linked_source(Path), Cwd)
	end.

This function takes the rebar options for a given application and normalize the path relative to the user's preference. We could reasonably be able to automatically do that in the compiler based on user preferences, I think.

[ferd]

We should use the {source, FileName} compiler options coupled with the existing compiler_source_format value (handled in rebar_dir:format_source_file_name/2) to safely set the file format without switching the working directories, which may be problematic under some rebar3 usages (in shell, or as part of the programmatic interface)

[obi458]

{source, FileName}
Sets the value of the source, as returned by module_info(compile).

But this is NOT the value where crashes get the path!
Cause you can strip the source chunk and crashes still find the filename(with path)!!
This is not a solution!

[tsloughter]

Yea, we can't be switching the cwd all the time like this.

It sounds like there needs to be an OTP fix so the filename in stacktraces is the same as the source option.

[ferd]

@bjorng since you're playing with compiler stuff by now, do you have any suggestion or rationale behind the current behavior? It seems a bit annoying/risky to have to align the cwd before compiling any module when there's already a {source, Path} option?

[obi458]

There is no need to do it at any time, but if i make the release than it should be an option!

[c-bik]

@tsloughter and @ferd

It sounds like there needs to be an OTP fix so the filename in stacktraces is the same as the source option.

Do you know if there is a discussion on this in OTP?

Is there any recommended work around to follow in the mean time?

[ferd]

No guidelines. The few times I tried to bring it up, I had no response, but I can try to push for it again.

[c-bik]

Hi @ferd

but I can try to push for it again

Did you get a chance to do that? Any updates?

[ferd]

I couldn't get anything there but I opened an Erlang/OTP issue: https://bugs.erlang.org/browse/ERL-706

[ferd]

The OTP issue has been implemented. Custom builds of rebar3 (using only the latest versions) and specifying deterministic builds as compiler options will drop paths from both exceptions and will let things be set. Just set the right erl_opts options.

See erlang/otp#1976 for details.