-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rust stack backtrace filled with unknown on Windows 8.1 #33985
Comments
It's a very recent regression (couple of weeks maybe), I observe it too. |
@skiwi2 do you have some sample code that could be used to reproduce this? |
I'm running the following code: https://gist.github.com/skiwi2/ce188c7d3b13fe3e3dbdb5c5f0752cd1 (Please don't mind the quality) |
I was unfortunately unable to reproduce, @skiwi2 can you also gist the output of |
Ah and also, the panic message (e.g. the full output of one compile) would also be useful |
@alexcrichton What exactly do you mean by your last request? Do you want the program output (including logging statements), or some compilation output? |
The rustc and Cargo info files are up at https://gist.github.com/skiwi2/be1a8bf2171f3c1114a5fa65933e6732 |
@skiwi2 oh just along the lines of gisting the entire error (from the invocation of rustc/cargo all the way through to the next prompt). It looks like the snippet above may just be a subset? The panic message may be enough, but can't hurt to have more output! |
#33554 was merged on May 14, your rustc is from May 18, could that have caused the regression perhaps? |
Oh! I apologize, I thought this was about an ICE not for a normal panic (which this appears to be about). In that case, yes, it's likely closely related to #33554, which was implemented for security purposes. |
In the meantime if you do want backtraces and don't mind installing VC++ you can always use the |
Having the same issue on current stable gnu toolchain |
This is still occurring on recent nightlies: https://www.reddit.com/r/rust/comments/4zgzfk/is_there_an_unwrap_in_macro_form/d6vrvuw |
I have the same problem too on newest gnu nightly and stable. Edit: |
This is a stable -> stable regression, by the way, if it helps with prioritization. |
This issue affects me as well. It makes debugging really hard. Luckily I can switch to msvc for now, but I have to abandon most of my tooling (e.g. gdb, which AFAIK doesn't support msvc-built binaries; I also often link to mingw-built libraries). |
@MoreAxes |
The simplest solution is to revert #33554, but use |
One of concerns from #21889 (in addition to malicious executable replacement) were race conditions in |
If the windows implementation doesn't have those race issues then it definitely seems reasonable to just turn this back on on Windows. |
@petrochenkov The point is not whether |
This vulnerability is hard to reach, but I don't want to be introducing random vulnerabilities to all Rust programs. |
You assume feeding an arbitrary ill-formed PE/COFF to libbacktrace is indeed a vulnerability, I haven't seen this confirmed so far. By default it sounds like "feeding an arbitrary text to rustc is vulnerability". |
Update: PreludeDWARF debug info is used on Windows/GNU, as opposed to PDB debug info on Windows/MSVC. The problemlibbacktrace needs to the read the executable file to extract DWARF debug info from it. In any case, the executable file is read and interpreted by libbacktrace whether we provide the filename to So, why don't we patch libbacktrace like this commit does and use Possible solutions
|
Note that the names of statically linked functions are also only specified in the debuginfo. Without debuginfo all you get is the names of functions that are exported from a DLL, and because Rust statically links everything by default, this means all Rust functions end up as unnamed, not even a mangled name. |
Regarding @alexcrichton 's alternatives from #37359 (comment)
Unless there's a way to somehow automatically read DWARF into a process' memory with OS' help, I don't see a way to avoid reading it from a file.
This means either even more invasive changes in libbacktraces to make it secure enough (how to determine if it's secure enough?), or find a readily available more secure version of libbacktrace (any concrete variants? how to determine if the alternative is secure enough?), or rewrite libbacktrace by ourselves (how to determine if our rewrite is secure enough?). Why do we think libbacktrace is not secure enough? I haven't seen any proofs that unintentional code-execution is possible yet. |
This is done by adding a function that can return a filename to pass to backtrace_create_state. The filename is obtained in a safe way by first getting the filename, locking the file so it can't be moved, and then getting the filename again and making sure it's the same. See: rust-lang#37359 (comment) Issue: rust-lang#33985
…trochenkov Make backtraces work on Windows GNU targets again. This is done by adding a function that can return a filename to pass to backtrace_create_state. The filename is obtained in a safe way by first getting the filename, locking the file so it can't be moved, and then getting the filename again and making sure it's the same. See: #37359 (comment) Issue: #33985 Note though that this isn't that pretty... I had to implement a `WideCharToMultiByte` wrapper function to convert to the ANSI code page. This will work better than only allowing ASCII provided that the ANSI code page is set to the user's local language, which is often the case. Also, please make sure that I didn't break the Unix build.
Fixed by #39234 |
@petrochenkov, with current implementation application crashes in the case of panic, if debug info is stripped out with (strip -s helloworld.exe) and RUST_BACKTRACE is set to 1. |
@dpelevin |
When running a piece of code I get the following stack backtrace:
I'm running
cargo build
withRUST_BACKTRACE=1
and have the following%PATH%
:I have no clue why it is not showing more information about the stack frames and haven't had any success in Googling it.
The text was updated successfully, but these errors were encountered: