On 31.08.2013 13:49, Lieven Govaerts wrote:
> Hi,
>
> I've been looking at the crash reports for TSVN on crash-server.com,
> specifically those related to the serf library.
>
> When analyzing the reports and associated dump files, I've often found
> that not enough information was available to correctly assess the
> context of when the issue occurred. The stack trace alone is not
> sufficient, especially because:
> a) the stack trace available directly on the website only shows function names
> b) I've noticed in the detailed stack traces that Stefan Küng sends to
> the svn-dev mailing list that the line numbers do not match with the
> source code (there is an offset).
If they have an offset, then most likely you don't use the exact same
files. Or: the files have inconsistent EOLs and the debugger then
calculates the line numbers wrong.
> c) the minidump files that I've downloaded never had function
> parameter or local variable values for code in the svn or serf
> library, at least, the values were corrupt from the point where the
> the code path entered the svn library.
> Note: for analysing the 1.8.1 minidumps I've used the 1.8.1 symbol
> files, so there shouldn't be a version mismatch involved.
You should use the exact debug symbols I used for the build. Those debug
symbols are stored on the crash-server.com server.
You have to set the SYMBOLS env variable to:
http://www.crash-server.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv
or better:
SET LOCAL_PDB_CACHE=%WINDBG_FOLDER%\sym
SET
SYMBOLS=srv*%LOCAL_PDB_CACHE%*http://www.crash-server.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv;srv*%LOCAL_PDB_CACHE%*http://msdl.microsoft.com/download/symbols
SET SOURCES=srv*
if you're using VisualStudio:
Debug->Options and settings
Symbols->Symbol file (.pdb) locations
add the url
http://www.crash-server.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv
there.
That way your debugger will download the correct debug symbols
automatically from the server where they're stored.
(have a look at the "opendump.cmd" file that's in every crash zip)
About the not-matching source files: you can configure your debugger to
automatically get the correct files from the svn repositories.
For WinDbg:
First create a file named srcsrv.ini and add the following:
[variables]
[trusted commands]
svn.exe
svn.exe export
If you're using Visual Studio:
Debug->Options and settings
Debugging->General->Enable Source Server Support
> d) even with a correct stack trace and all local variable values
> available, it still misses some contextual information. For serf that
> means proxy config, authentication types etc.
>
> So, is there anything that can be done to solve this?
Where is that information stored and how could I get it?
As you know, a crash dump only contains information from the immediate
context of a crash. There are however full dumps sometimes available,
but that depends on the user: when a crash happens the user is asked to
send the full report, but most of the time the user doesn't do that.
You can see the full dumps on crash-server.com marked with a grade > 100.
>
> I'm looking now at issue 31544 libsvn_tsvn!serf__open_connections
I've created an issue for the 1.8.2 version of this crash:
https://www.crash-server.com/Problem.aspx?ClientID=tsvn&ProblemID=36314
and marked is as "waiting for new dump" with a grade > 100 (which means
a full dump).
> (which apparently still happens in TSVN 1.8.2). What I need to get a
> better understanding of the problem is:
> - url of the server
> - if a proxy server is configured, with or without user name and
> password (basic/digest vs NTLM/Negotiate authn)
> - the exact line of code where it fails
> - all function parameter variables in the stack trace
> - all local variable values
> - the user's local ip address, proxy ip address (ipv4 vs ipv6)
> - amount of memory in use, amount of memory available
For full dumps, the zip file contains two xml files with some more
information (e.g., memory use, available memory).
> I suppose if I can get issues b and c solved, I'll have most of the
> required info since I get the relevant context from the svn ra_session
> and serf serf_session_t objects.
>
> So, question 1: Is it possible to read those minidump files and get
> correct crash location and all the relevant variable values?
crash location: yes. Just set up your debugger as I described above.
relevant variable values: it will be better with full dumps, but even
those don't contain everything.
> Question 2: if this is not possible, can you log certain information
> and send it with the crash report to crash-server.com were I can read
> it?
That depends. First I need a way to get that information. And second: if
that information is only available during an operation, it has to be
stored somewhere safe and must be easily accessible.
The problem with such info is that when a crash happens, the process
memory is usually corrupted and therefore a crash reporter tool can not
access all information of that process.
I can add info to a crash report during runtime. That info is then
available for such reports where the user sends more information if
asked to, but not for those which are marked with grade 4 or grade 6 on
the crash-server.com website.
The info is stored as key/value pairs.
So I would need a way to get that information from maybe a callback
because the info you need here will only be available after I call the
svn API.
> Alternative 1: I seem to have no problem reading variables in the tsvn
> part of a stack trace, so a global 'debug' object with some values or
> some lines of logging would be helpful here.
> Alternative 2: there was a request on the svn mailing list to be able
> to enable serf logging at runtime. This hasn't been implemented yet,
> but when it is, It'd be nice of tsvn could upload warning and error
> log lines together with the crash reports.
Of course, as soon as runtime-logging is implemented, I'll add that
feature to TSVN as well.
I can also add files (e.g. logfiles) to the crash report.
Would it help if I add the svn config file?
Of course, that file would only be available in crash dumps with grade >
100, meaning only for those reports where the user decides to send more
information.
To see what the dialog looks like and how the user is asked to send more
info, run
TortoiseProc.exe /command:crash
The user is only asked if there are no full dumps already available for
that specific crash, or if we mark the issue as "waiting for dump".
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3063682
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-31 14:33:43 CEST