Re: 'svn ls -v URL' segfault

On Wed, Mar 19, 2003 at 09:40:46PM -0600, Ben Collins-Sussman wrote:
>...
> $ svn ls -v http://svn.collab.net/repos/svn/branches
> Segmentation fault (core dumped)
>
> The sefault happens on line 73 of ls-cmd.c; svn_utf_cstring_from_utf8
> tries to convert a NULL dirent->last_author. Most of the dirent's
> fields are NULL, actually, which ain't right.
>
> The server hasn't changed: ethereal is still sending the
> creator-displayname DAV property, but fetch.c:set_special_wc_prop()
> isn't being called at all, according to gstein. (He put a printf()
> into that function, and never saw the message!)

In retrospect, that was the wrong place to look. After further searching, I
isolated the problem to some property handling code in ra_dav/props.c. I
patched it up in rev 5400, but the net result was disabling reception of
binary properties in the client.

I talked with Mike about it for a bit. We've got a couple things going on in
ra_dav w.r.t property handling:

1) some properties are handled via Neon's prop handling
2) some properties are handled by working with the XML directly

Specifically, we use (2) to extract URLs out of properties that look like:

<D:baseline-collection><D:href>/repos/!svn/bc/5/</D:href></D:baseline-collection>

If we had used Neon's property handling, we'd have to parse out the D:href
elements to get at the CDATA.

The problem is that we want to recognize properties like:

<S:user-prop V:encoding="base64">dkalkjfljfd</S:user-prop>

and extract that V:encoding attribute. However, we can only do that through
the (2) code rather than Neon's prop handling. So Mike made the alterations,
and everything look fine and dandy. But it also altered Neon's prop
handling, so it stopped passing stuff to our (1) code. That dropped out the
recognition and storage of DAV:creator-displayname, and so the author was
never set, so the 'svn ls' command tanked.

Mike and I tentatively decide to forget about binary prop reception in 0.20
for now. The fix is non-obvious, so we're thinking about reviewing our DAV
prop handling code. Pending a better idea, I'm inclined to use Neon's XML
handling, but to do our own property response parsing.

Another possibility might be a review of the Neon APIs and some discussion
and patches back to Joe. The basic issue is this part of a DAV response:

  <D:prop>
    <S:property V:encoding="foo" a:some-attr="bar">baz</S:property>
  </D:prop>

Strictly speaking, the attributes on S:property are not part of the property
value, so there is an argument that they shouldn't be passed along to the
property-value handling code. However, those attributes can certainly
include metadata to control the interpretation of the value. We want an
encoding property, but there are also standard props like xml:lang which
most definitely alter how to view that prop.

Going further, the XML spec says that xml:lang is scoped. Thus, a property
handler really needs to "hear about it" from any possible scope. Not just
attrs on the property element. It may be that Neon needs to treat that one
special, so then you ask how to create a general solution -- are there other
metadata items that might have to scope, too?

If we decide to manage the prop response parsing, then we might be able to
suggest some new Neon APIs to Joe to help us leverage the existing code
within Neon rather than duplicating all of it. (of course, we can fine-tune
a lot of our handling rather than a general solution like Neon)

Any thoughts?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org