Hi,
I've investigated the crash dump provided on the users mailing list in
the thread: "Subversion crash report".
Not sure what exactly the underlying issue is, but doing a code review
suggests that SVN is making use of a nullptr without properly checking
that case.
starting in libsvn_wc/conflicts.c: build_text_conflict_resolve_items():
1. The call to svn_wc__conflict_read_text_conflict() sets mine_abspath
to null without returning an error (I assume this is correct behavior
here). Therefore, it looks like m->is_atom is false in this case (inside
svn_wc__conflict_read_text_conflict()).
2. If the user chooses "svn_wc_conflict_choose_theirs_conflict" or
"svn_wc_conflict_choose_mine_conflict" that null-ptr is being passed on
to merge_showing_conflicts().
3. merge_showing_conflicts() passes that then on to
svn_diff_file_diff3_2(), then to svn_diff_diff3_2() (in
baton.files[1].path), then to vtable->datasources_open() (in the
diff_baton), opens it with svn_io_file_open() where cstring_from_utf8()
doesn't trigger an error on Windows/Mac (see other thread).
I take it that build_text_conflict_resolve_items() is missing a
null-check for mine_abspath() in the switch case before calling
merge_showing_conflicts() (according to what that function does, if
install_from_abspath is null), but then I take it that you are more
familiar with the intended behavior here (maybe the missing null-check
on Windows would be sufficient to restore the originally intended
behavior?).
Regards,
Stefan
