-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
RAR BadImageReferenceException needs to log the callstack and exception type #6224
Comments
@KirillOsenkov are you investigating this currently? /cc: @Forgind |
No, this one is up-for-grabs if anyone’s interested |
If so, does #6240 look about how you expected? |
Yes, perfect. |
And for completeness, I've found the underlying issue that was causing an AccessDenied exception. Zip on .NET doesn't preserve file permissions, so unpacking the Zip on Mac was creating files with 0 permissions instead of 644: |
Seeing that it was Access Denied and the full ToString() would have certainly helped. |
This looks a bit ugly to the user though
do we want to show these internal frames here? |
Not sure what’s the best way to truncate them: just keep the first text line from ToString() or take just the message from the innermost exception? |
I'm not sure what other variations look like or what information you expect the user to get from them? Maybe log the message normally, but reserve ToString (or StackTrace) for the highest verbosity logging? In this case, the dll was corrupted, when I see callstack from my build tool it makes me think there is a bug in it. |
I agree showing the callstack is unpolished, just curious on how to actually fix this. Because there are nested exceptions so we should probably print the message from each nested exception? |
For the aggregated message including nested you could concat something like [AggregateException does]?(https://github.com/dotnet/runtime/blob/fc854d9921475366875658180afa495d452451be/src/libraries/System.Private.CoreLib/src/System/AggregateException.cs#L346-L367) For the diagnostic verbosity, you could dump ToSTring() which will include nested info. |
I'm not opposed to trying to make this clearer/simpler, but it seems lower priority than getting the information out, so I removed my assignment. I'm curious if this could be an opportunity to use the check-verbosity-before-logging idea. Diagnostic --> current behavior. Quiet/minimal --> nothing? Normal --> message from innermost exception? |
I guess I meant log the error with the messages, and immediately follow with a low importance message event with the ToString(), perhaps. |
I just hit this a few times building dotnet/runtime. The output folder was "slightly corrupt" I guess. I believe a tool that dumps stack to the console looks like it has a bug. I put up a fix. |
Fixes #6224 Context See issue -- a change was made to add more detail when RAR fails to resolve a reference due to encountering a BIFE. This added too much detail -- not only the message from the inner exception, but also the callstack. We should not dump callstack when there is no bug in MSBuild (or a task/logger). Oddly enough I hit this again #8140 and didn't remember the original discussion, and therefore again assumed there was a bug. Changes Made Fix BIFE to include the message from any inner exception. (There was a suggestion in the issue that it also include the exception type, but I don't know of any case where the type is necessary in order to disambiguate what happened, and we don't have precedent for doing it. It would also be ugly.) Revert the original change, now unnecesssary. Testing Added test that fails without the fix.
I'm investigating a build with this warning from RAR:
This exception is thrown in four places:
https://source.dot.net/#Microsoft.Build.Tasks.Core/AssemblyDependency/BadImageReferenceException.cs,cbeccdcba5e80a17,references
It could be a
BadImageFormatException
,FileNotFoundException
,FileLoadException
or any other IORelated exception. We throw away the callstack and don't display the type of the underlying exception. We should print the original exception ToString() not just the Message.The text was updated successfully, but these errors were encountered: