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
