On Wed, Jan 22, 2020 at 2:36 PM Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:
> Nathan Hartman wrote on Wed, 22 Jan 2020 11:00:20 -0500:
> > According to the OP's stack trace, the exception was an access
> > violation in svn_fs_print_modules():
> >
> > Stacktrace:
> > #1 0x7fff2af55583 in svn_fs_print_modules()
> > #2 0x7fff2af5627d in svn_fs_create2()
>
> How is this stack state possible? svn_fs_create2() doesn't call
> svn_fs_print_modules() directly or indirectly. The latter function
> isn't called from _anywhere_ in svnadmin except subcommand_help().
I had this thought:
> In order for a program to print a stack trace with names, it must have
symbol name information available to it. It clearly printed gibberish here.
In addition to this impossible sequence of calls, there were also four
"unknown" functions in that trace. That might be plausible if the svn
libraries were used from within an application but the OP reported using
svnadmin on the command line. This leads me to believe that addresses were
mapped to incorrect names, and as such the access violation probably didn't
occur in svn_fs_print_modules().
Nathan
Received on 2020-01-23 06:00:20 CET