You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nathan Hartman <ha...@gmail.com> on 2020/01/22 16:00:20 UTC
Re: DUMP Error
Moving from users@:
On Tue, Jan 21, 2020 at 8:31 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Tue, 21 Jan 2020 14:26 +00:00:
> > The FSX back end is a work in progress and not ready for production use.
>
> Then shouldn't «svnadmin create --fs-type=fsx» emit a warning to that effect, like --fs-type=bdb does?
It could with a patch like the one below (which is INCOMPLETE because
create_repos() in subversion/tests/cmdline/svntest/main.py needs to be
adjusted to expect this extra output)...
BUT:
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()
#3 0x7fff0e7c03b6 in svn_repos_create()
#4 0x7ff751112e46 in (unknown function)
#5 0x7ff7511138de in (unknown function)
#6 0x7ff75111699d in (unknown function)
#7 0x7ff7511111e2 in (unknown function)
#8 0x7fff37da7bd4 in BaseThreadInitThunk()
#9 0x7fff3880ced1 in RtlUserThreadStart()
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?
That was with 1.12.0 on Windows and I haven't investigated further.
Maybe failed pool allocations are reported that way on Windows?
INCOMPLETE patch (affects subcommand_create()):
[[[
Index: subversion/svnadmin/svnadmin.c
===================================================================
--- subversion/svnadmin/svnadmin.c (revision 1873037)
+++ subversion/svnadmin/svnadmin.c (working copy)
@@ -865,6 +865,21 @@
"svnadmin: ", SVN_FS_TYPE_BDB, SVN_FS_TYPE_FSFS));
fflush(stderr);
}
+
+ /* FSX should not be used in production yet. Currently, it is
+ * for experimental and development use. Until it is ready, warn
+ * users if they choose FSX. */
+ if (0 == strcmp(opt_state->fs_type, SVN_FS_TYPE_FSX))
+ {
+ SVN_ERR(svn_cmdline_fprintf(
+ stderr, pool,
+ _("%swarning:"
+ " The \"%s\" repository back-end is EXPERIMENTAL,"
+ " consider using \"%s\" instead.\n"),
+ "svnadmin: ", SVN_FS_TYPE_FSX, SVN_FS_TYPE_FSFS));
+ fflush(stderr);
+ }
+
svn_hash_sets(fs_config, SVN_FS_CONFIG_FS_TYPE, opt_state->fs_type);
}
]]]
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. :-)
Nathan
Re: DUMP Error
Posted by Nathan Hartman <ha...@gmail.com>.
Forgot to "Reply All" (again). Forwarding my reply to the list:
On Wed, Jan 22, 2020 at 2:36 PM Daniel Shahaf <d....@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().
That is really weird.
It will take more digging to figure out what happened here.
Meanwhile:
> Seems to DTRT here:
Thanks for testing that. It's comforting to know that invalid inputs
don't run us off the road.
>> 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
I meant the infamous tab between the filename and the revision in the
diff header. :-)
Cheers,
Nathan
Re: DUMP Error
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Jan 22, 2020 at 2:36 PM Daniel Shahaf <d....@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
Re: DUMP Error
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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