backtrace-labs / backtrace-csharp Goto Github PK

LoadReports (https://github.com/backtrace-labs/backtrace-csharp/blob/dev/Backtrace/BacktraceDatabase.cs#L373) doesn't handle the potential null returned by ReadFromFile when invalid JSON is found (https://github.com/backtrace-labs/backtrace-csharp/blob/dev/Backtrace/Model/Database/BacktraceDatabaseRecord.cs#L314) before using record.

Should we have a if (!record) continue; after the ReadFromFile call?

Specifically, if I add a null attribute, then try to save a report to the database, it fails.

Example Code:

string attrib;
_client.Attributes["attrib"] = attrib;
_client.Database?.Add( report, _client.Attributes, _client.MiniDumpType );

This can happen when assigning strings to attributes which could be null.

Workaround is to check before assigning a attribute

string attrib;
if ( !String.IsNullOrEmpty(attrib) )
{
_client.Attributes["attrib"] = attrib;
}

Our EXE is a native EXE that ends up calling into .NET through interop.

In this situation we have found the following code that crashes with a index out of range exception and then we end up losing the crash report.

In BacktraceAttributes.cs

        private void SetDebuggerAttributes(Assembly callingAssembly)
        {
            object[] attribs = callingAssembly.GetCustomAttributes(typeof(DebuggableAttribute), false);
   ...
            if (attribs[0] is DebuggableAttribute debuggableAttribute)   <------ this will throw a index out of range exception

The exception is thrown because a native EXE won't have the custom attributes on it

I would recommend changing the code in the if statement to something like the following

            if ( attribs != null && attribs.Length > 0 &&
                 attribs[0] is DebuggableAttribute debuggableAttribute )

We recently added the backtrace-csharp SDK to a product and noticed the following behavior while offline.

While offline if a crash occurs, it is taken correctly, it is added to the cache directory.

While still offline when restarting the application, the crash is deleted.

Is this behavior expected/by design? We would have expected the crash to continue to be saved while offline.

Relevant callstack:

Unhandled exception. System.ArgumentException: The path is empty. (Parameter 'path')
   at System.IO.Path.GetFullPath(String path)
   at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
   at Backtrace.Model.JsonData.BacktraceAttributes.SetLibraryAttributes(BacktraceReport report)
   at Backtrace.Model.JsonData.BacktraceAttributes..ctor(BacktraceReport report, Dictionary`2 clientAttributes)
   at Backtrace.Model.BacktraceData.SetAttributes(Dictionary`2 clientAttributes)
   at Backtrace.Model.BacktraceData..ctor(BacktraceReport report, Dictionary`2 clientAttributes)
   at Backtrace.Base.BacktraceBase.Send(BacktraceReport report)
   at Backtrace.BacktraceClient.Send(BacktraceReport backtraceReport)
   at Backtrace.BacktraceClient.Send(Exception exception, Dictionary`2 attributes, List`1 attachmentPaths)

The long and short of it is that BacktraceAttributes.SetLibraryAttributes is trying to get the calling assembly's location via Assembly.Location as a reporting attribute, along with passing it to FileVersionInfo.GetVersionInfo to get the version information here.

Assembly.Location always returns the empty string when PublishSingleFile is enabled.

To repro the issue:

1. Add backtrace to an example project and create a BtClient
2. call BtClient.Error(new Exception("test")); in Main
3. dotnet publish /p:PublishSingleFile=true --self-contained true -r win-x64
4. Run the resulting exe

This seems like a bad cast - Any other types derived from BacktraceReportBase will end up nulled out here. Is it intentional that only the BacktraceReport subclass be allowed? If so, the Report/ReportBase seems needlessly complex and confusing.