You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by an...@gnulinux.dk on 2002/06/08 06:55:27 UTC

[BUGREPORT] Problems with diff, maybe related to i18n

[BUGREPORT] Probably i18n stuff Reply-To: 

Hello there

We are a group of danish translaters who just started using your nice
piece of software. This also means that we should give the i18n support
(or lag of) a good amount test :-)
For the record our repository is located here:
http://www.gnulinux.dk/svn/gentoo-doc-dk.

Your first problem was that we can't use danish characters in changelogs.
This is of course related to i18n support. And yes we know it's still
pre-alpha software. We just thought we might give you some real world
feedback :-) 

We checked our source-code in and began to play with the different svn
options. svn diff -r x:y segmentation faults on our archive, it displays
the diff but then segfaults right before it quits. I tried svn diff -r x:y
on the main svn archive and that worked fine. This is maybe related to
i18n since most of the documents in the repository is danish.

mdk (I think it was) on #svn guided the through gdb and I hope this might
be helpful in solving the problem.

(gdb) bt

#0  0x40046475 in wrap_change_dir_prop (dir_baton=0x0, name=0x8089d78, 
    value=0x8089d90) at subversion/libsvn_delta/default_editor.c:364
#1  0x40053b12 in simple_store_vsn_url (
    vsn_url=0x8089e78 "/svn/gentoo-doc-dk/!svn/ver/2/", baton=0x0, 
    setter=0x40046458 <wrap_change_dir_prop>, vuh=0x808196c)
    at subversion/libsvn_ra_dav/fetch.c:205
#2  0x400557ad in end_element (userdata=0x8081940,elm=0x4005b5d0, 
    cdata=0x807d598 "/svn/gentoo-doc-dk/!svn/ver/2/")
    at subversion/libsvn_ra_dav/fetch.c:1568
#3  0x40161d87 in end_element (userdata=0x807cd48, name=0x8099f36 "D:href")
    at ne_xml.c:562
#4  0x4010ddf1 in XML_GetBuffer () from /usr/lib/libexpat.so.0
#5  0x4010f75a in XML_GetBuffer () from /usr/lib/libexpat.so.0
#6  0x4011455e in XML_ExpatVersionInfo () from /usr/lib/libexpat.so.0
#7  0x401133ab in XML_ExpatVersionInfo () from /usr/lib/libexpat.so.0
#8  0x401130c5 in XML_ParseBuffer () from /usr/lib/libexpat.so.0
#9  0x4011306b in XML_Parse () from /usr/lib/libexpat.so.0
#10 0x40162641 in ne_xml_parse (p=0x807cd48, 
    block=0xbfffd7ac "<?xml version=\"1.0\"
encoding=\"utf-8\"?>\n<S:update-report xmlns:S=\"svn:\"
xmlns:D=\"DAV:\">\n<S:target-revision rev=\"2\"/>\n<S:replace-directory
rev=\"1\">\n<D:checked-in><D:href>/svn/gentoo-doc-dk/!svn/ver/2/</"...,
len=1197) at ne_xml.c:802
#11 0x40162532 in ne_xml_parse_v (userdata=0x807cd48, 
    block=0xbfffd7ac "<?xml version=\"1.0\"
encoding=\"utf-8\"?>\n<S:update-report xmlns:S=\"svn:\"
xmlns:D=\"DAV:\">\n<S:target-revision rev=\"2\"/>\n<S:replace-directory
rev=\"1\">\n<D:checked-in><D:href>/svn/gentoo-doc-dk/!svn/ver/2/</"...,
len=1197) at ne_xml.c:777
#12 0x401605fb in gz_reader (ud=0x808dd40, 
    buf=0xbfffd7ac "<?xml version=\"1.0\"
encoding=\"utf-8\"?>\n<S:update-report xmlns:S=\"svn:\"
xmlns:D=\"DAV:\">\n<S:target-revision rev=\"2\"/>\n<S:replace-directory
rev=\"1\">\n<D:checked-in><D:href>/svn/gentoo-doc-dk/!svn/ver/2/</"...,
len=1197) at ne_compress.c:266
#13 0x40156a48 in ne_read_response_block (req=0x80620d8, 
    buffer=0xbfffd7ac "<?xml version=\"1.0\"
encoding=\"utf-8\"?>\n<S:update-report xmlns:S=\"svn:\"
xmlns:D=\"DAV:\">\n<S:target-revision rev=\"2\"/>\n<S:replace-directory
rev=\"1\">\n<D:checked-in><D:href>/svn/gentoo-doc-dk/!svn/ver/2/</"...,
buflen=8192) at ne_request.c:734
#14 0x40157d1f in ne_request_dispatch (req=0x80620d8) at ne_request.c:1271
#15 0x4005876a in svn_ra_dav__parsed_request (ras=0x8081660, 
    method=0x40059649 "REPORT", url=0x805d128 "/svn/gentoo-doc-dk",
body=0x0, 
    fd=3, elements=0x4005b4a0, validate_cb=0x40054c78 <validate_element>, 
        startelm_cb=0x40054eec <start_element>, 
	    endelm_cb=0x40055594 <end_element>, baton=0x8081940, pool=0x8058fd8)
	        at subversion/libsvn_ra_dav/util.c:271
#16 0x40055d7f in reporter_finish_report (report_baton=0x8081940)
   at subversion/libsvn_ra_dav/fetch.c:1764
#17 0x40020b47 in do_diff (options=0x8059250,
auth_baton=0x8059238, 
    path1=0x8059340 ".", revision1=0xbffffac4, path2=0x8059340 ".", 
        revision2=0xbffffad0, recurse=1, callbacks=0x40026288, 
	    callback_baton=0xbffff94c, pool=0x8058fd8)
	        at subversion/libsvn_client/diff.c:1061
#18 0x40020c10 in svn_client_diff (options=0x8059250,
auth_baton=0x8059238, 
    path1=0x8059340 ".", revision1=0xbffffac4, path2=0x8059340 ".", 
        revision2=0xbffffad0, recurse=1, outfile=0x8059280,
errfile=0x80592c8, 
    pool=0x8058fd8) at subversion/libsvn_client/diff.c:1149
#19 0x0804aca5 in svn_cl__diff (os=0x8059138, opt_state=0xbffffac4, 
    pool=0x8058fd8) at subversion/clients/cmdline/diff-cmd.c:171
#20 0x0804c7c8 in main (argc=4, argv=0xbffffb94)
    at subversion/clients/cmdline/main.c:1121
#21 0x4020f3bd in __libc_start_main () from /lib/libc.so.6

(gdb) up
#1  0x40053b12 in simple_store_vsn_url (
    vsn_url=0x8089e78 "/svn/gentoo-doc-dk/!svn/ver/2/", baton=0x0, 
        setter=0x40046458 <wrap_change_dir_prop>, vuh=0x808196c)
	    at subversion/libsvn_ra_dav/fetch.c:205
	    205					     err =
(*setter)(baton, vuh->name, vuh->value);

(gdb) up
#2  0x400557ad in end_element (userdata=0x8081940, elm=0x4005b5d0, 
    cdata=0x807d598 "/svn/gentoo-doc-dk/!svn/ver/2/")
        at subversion/libsvn_ra_dav/fetch.c:1568
	1568					          CHKERR(
simple_store_vsn_url(rb->href->data, TOP_DIR(rb).baton,

(gdb) p *(report_baton_t *)userdata
$1 = {ras = 0x8081660, tmpfile = 0x8081a00, fetch_content = 1, 
  fetch_props = 1, editor = 0x8081908, edit_baton = 0x80818f8, 
    dirs = 0x8081b80, file_baton = 0x0, namestr = 0x807fba8, 
      cpathstr = 0x807fbc0, href = 0x8089d48, vuh = {name = 0x8089d78, 
          value = 0x8089d90}, current_wcprop_path = 0x808a7c8 "", err = 0x0}
	  
(gdb) p *((report_baton_t *)userdata)->dirs
$2 = {pool = 0x8058fd8, elt_size = 16, nelts = 0, nalloc = 5, 
elts = 0x8081b98 " =\t\b"}

What he found interesting was that baton was 0 (in bt:#1) and that nelts
is also 0 in the latest debug message which they shouldn't be.

-- 
Anders Rune Jensen
jabber: superduck@myjabber.net | email : anders@gnulinux.dk

Re: [BUGREPORT] Problems with diff, maybe related to i18n

Posted by Karl Fogel <kf...@newton.ch.collab.net>.
anders@gnulinux.dk writes:
> Your first problem was that we can't use danish characters in changelogs.
> This is of course related to i18n support. And yes we know it's still
> pre-alpha software. We just thought we might give you some real world
> feedback :-) 

Thanks for the feedback!

There are now concrete plans to fix this problem, see

   http://subversion.tigris.org/issues/show_bug.cgi?id=722

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUGREPORT] Problems with diff, maybe related to i18n

Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:

> On Sat, Jun 08, 2002 at 08:59:26AM -0500, Ben Collins-Sussman wrote:
> > anders@gnulinux.dk writes:
> > 
> > > We checked our source-code in and began to play with the different svn
> > > options. svn diff -r x:y segmentation faults on our archive
> > 
> > It was a client-side bug that I wrote, and just fixed in r2128.
> > 
> > Go ahead and update/rebuild your client, it should work now.
> 
> Sounds like we should also fix the client/server to *not* send the data on a
> simple diff.

Hmmm, not sure how we would do that.  There is no "simple diff".  :-)

'svn diff -r5 wcpath', which compares your working wcpath against r5
of it, is done by running an update under the hood.  The working copy
is described to the server, and when parsing the response, we GET
tmpfiles and compare to working files.

 'svn diff URL1 URL2' runs a switch under the hood (instead of
 update), since the urls aren't necessarily related.  This method is
 also used for the 'svn diff -rX:Y [URL|wcpath]' case.

As far as mod_dav_svn is concerned, it only sends the "extra"
vsn-rsc-url data for a switch.  That was a recent change.

Really, we're getting wcprops sent back to us *embedded* in the update
and switch responses anyway... we always have.  It's just that
operations like 'svn diff' and 'svn st -u' deliberately set the
set_wcprop() callback to NULL, so the vsn-rsc-urls are ignored during
parsing.

Maybe we could add some custom request header that will tell
mod_dav_svn to leave out all the vsn-rsc-urls, both within the response
and in the resource-walk?  Do we really care?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUGREPORT] Problems with diff, maybe related to i18n

Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jun 08, 2002 at 08:59:26AM -0500, Ben Collins-Sussman wrote:
> anders@gnulinux.dk writes:
> 
> > We checked our source-code in and began to play with the different svn
> > options. svn diff -r x:y segmentation faults on our archive
> 
> It was a client-side bug that I wrote, and just fixed in r2128.
> 
> Go ahead and update/rebuild your client, it should work now.

Sounds like we should also fix the client/server to *not* send the data on a
simple diff.

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

Re: [BUGREPORT] Problems with diff, maybe related to i18n

Posted by Ben Collins-Sussman <su...@collab.net>.
anders@gnulinux.dk writes:

> We checked our source-code in and began to play with the different svn
> options. svn diff -r x:y segmentation faults on our archive

It was a client-side bug that I wrote, and just fixed in r2128.

Go ahead and update/rebuild your client, it should work now.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUGREPORT] Problems with diff, maybe related to i18n

Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:

> anders@gnulinux.dk writes:
> 
> > For the record our repository is located here:
> > http://www.gnulinux.dk/svn/gentoo-doc-dk.
> > 
> > We checked our source-code in and began to play with the different svn
> > options. svn diff -r x:y segmentation faults on our archive, it displays
> > the diff but then segfaults right before it quits.
> 
> Yup, this is perfectly reproducible with any remote client.  Just run 
> 
>    svn diff -r3:4 http://www.gnulinux.dk/svn/gentoo-doc-dk
> 
> And you get the segfault.  I'm gdb'ing it now.
> 
> For some reason, libsvn_ra_dav/fetch.c is trying to store a
> vsn-rsc-url when there is no working copy!  

Okay, I think I know what the bug is.

'svn diff' uses the standard update REPORT request, so it can parse
the server response and knows what files to fetch & diff.

I recently fixed a bug with 'svn switch' so that the REPORT-response
would have an extra "resource walk" at the end, for updating
vsn-rsc-urls.  

If you run 'svn diff' against svn.collab.net, which is running an old
version of mod_dav_svn, it doesn't send the extra vsn-rsc-url walk;
but if you run it against Anders' repository, we're definitely getting
the extra data in the repsonse.

I've got to run out now... but the solution is in the case of 'svn
diff', either (1) ra_dav must tell mod_dav_svn not to do the extra
resource-walk, or (2) ra_dav must deliberately ignore it.  I can't
remember the mechanics, I'd have to look at the code again.  If it
isn't fixed when I get back later today, I can do it myself.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUGREPORT] Problems with diff, maybe related to i18n

Posted by Ben Collins-Sussman <su...@collab.net>.
anders@gnulinux.dk writes:

> For the record our repository is located here:
> http://www.gnulinux.dk/svn/gentoo-doc-dk.
> 
> We checked our source-code in and began to play with the different svn
> options. svn diff -r x:y segmentation faults on our archive, it displays
> the diff but then segfaults right before it quits.

Yup, this is perfectly reproducible with any remote client.  Just run 

   svn diff -r3:4 http://www.gnulinux.dk/svn/gentoo-doc-dk

And you get the segfault.  I'm gdb'ing it now.

For some reason, libsvn_ra_dav/fetch.c is trying to store a
vsn-rsc-url when there is no working copy!  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org