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().
> Also I notice that the command was:
> C:\ >svnadmin create --fs-type fs_x %SVN_HOME%\repos\newProjectRepos
>
> Note the --fs-type fs_x rather than fsx. That doesn't seem right.
> Maybe any garbage passed in the --fs-type parameter will cause an
> access violation?
Seems to DTRT here:
[[[
% svnadmin create --fs-type "$(head /dev/urandom)" "$(mktemp -d)"
/home/daniel/src/svn/t1/./subversion/svnadmin/svnadmin.c:3112,
/home/daniel/src/svn/t1/./subversion/libsvn_subr/utf.c:651:
(apr_err=EINVAL) svnadmin: E000022: Valid UTF-8 data
(hex:)
followed by invalid UTF-8 sequence
(hex: 99 c9 41 2c)
zsh: exit 1 svnadmin create --fs-type "$(head /dev/urandom)"
"$(mktemp -d)" % svnadmin create --fs-type "$(strings /dev/urandom |
head -3)" "$(mktemp
-d)" /home/daniel/src/svn/t1/./subversion/svnadmin/svnadmin.c:918, /home/daniel/src/svn/t1/./subversion/libsvn_repos/repos.c:1197,
/home/daniel/src/svn/t1/./subversion/libsvn_fs/fs-loader.c:536,
/home/daniel/src/svn/t1/./subversion/libsvn_fs/fs-loader.c:315:
(apr_err=SVN_ERR_FS_UNKNOWN_FS_TYPE) svnadmin: E160033: Unknown FS type
'R?)CY' zsh: exit 1 svnadmin create --fs-type
"$(strings /dev/urandom | head -1)" "$(mktemp -d)" %
]]]
That's on Linux, in maintainer mode, with
--enable-runtime-module-search set to its default value.
> And this patch won't apply because my stupid MUA will change the tabs to
> spaces, but I don't want it to apply because it's incomplete. So this is
> a feature, not a problem. :-)
Subversion's source code doesn't use tabs ☺
Cheers,
Daniel
Received on 2020-01-22 20:36:25 CET