On 6/15/06, Peter Fastré <peter.fastre@gmail.com> wrote:
>
>
>
> On 6/15/06, John Szakmeister <john@szakmeister.net> wrote:
> >
> > Something is terribly wrong. I don't know if it's the versions of the
> > libraries being picked up or what, but something is definitely wrong here.
> >
> > Instead of thinking that the bug is in Subversion, perhaps we should
> > take a different approach and start looking at the executable and things
> > around it. Have you tried taking a look at 'ldd svnlook'? Does anything
> > strange show up there? How about using strace and ltrace to see where
> > things are falling over?
>
>
> I don't have much time right now, but I can proceed my search for a
> solution this evening.
>
> I'm not sure what you can see in these results:
> root@smith:~# ldd /usr/local/bin/svnlook
> libsvn_repos- 1.so.0 => /usr/local/lib/libsvn_repos-1.so.0(0x40017000)
> libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0 (0x40033000)
> libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0(0x40039000)
> libsvn_fs_base-1.so.0 => /usr/local/lib/libsvn_fs_base-1.so.0(0x40052000)
> libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0(0x40074000)
> libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff- 1.so.0(0x4007c000)
> libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0(0x40083000)
> libaprutil-0.so.0 => /usr/local/apr/lib/libaprutil-0.so.0(0x400a8000)
> libgdbm.so.3 => /usr/local/lib/libgdbm.so.3 (0x400be000)
> libdb-4.2.so => /lib/libdb-4.2.so (0x400cd000)
> libexpat.so.0 => /usr/lib/libexpat.so.0 (0x401a0000)
> libapr-0.so.0 => /usr/local/apache2/lib/libapr- 0.so.0(0x401c0000)
> librt.so.1 => /lib/librt.so.1 (0x401e0000)
> libm.so.6 => /lib/libm.so.6 (0x401f3000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40217000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x40245000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x4025b000)
> libdl.so.2 => /lib/libdl.so.2 (0x402ad000)
> libc.so.6 => /lib/libc.so.6 (0x402b1000)
> /lib/ld-linux.so.2 (0x40000000)
>
>
> Please note, the svnlook command doesn't do a segfault all the times. It
> never works as it should, but it only does a segfault when accessing a
> FSFS-repository. BDB-repository's give a different error (end of file
> found), the same as I described in my opening post.
>
> root@smith:~# svnlook
> Type 'svnlook help' for usage.
> root@smith:~# svnlook diff /data/svn/framework/ -r 14 --> note:
> BDB-repository
> Modified: trunk/layouts/lunatis_admin/standard.php
> ===================================================================
> svnlook: Can't read file
> '/tmp/svnlook.41/trunk/layouts/lunatis_admin/standard.php.tmp': End of file
> found
> root@smith:~# svnlook diff /data/svn/framework --> note:
> BDB-repository
> Modified: trunk/layouts/lunatis_admin/include_menu.php
> ===================================================================
> svnlook: Can't read file
> '/tmp/svnlook.42/trunk/layouts/lunatis_admin/include_menu.php.tmp': End of
> file found
> root@smith:~# svnlook diff /data/svn/newrepos2 -r 1 --> note:
> FSFS-repository
> Segmentation fault
>
>
> I suspect there is some sort of library issue here. Can you try some of
> > the above things and see what you turn up? FWIW, I've never seen an issue
> > list this (and I've been watching the list for over 3 years!).
>
>
> I've never used the trace & rtrace commands, so I'll have to do some
> lookup how those commands work this evening.
> What library issues can be expected? What are we looking for? A library
> that doesn't exist or something?
>
> Regards
>
> Peter
>
I spent several hours on this subversion problem this weekend. The problem
has changed a little bit, the segmentation fault is gone after recompiling
and reinstalling subversion.
But still it isn't working.
When we execute the following commands, we get these strange messages:
First, the locale is set to en_US (which is default):
root@smith:~# svnlook diff /data/svn/newrepos2 -r 1
svnlook: Can't open directory
'/tmp/svnlook.50/P 2 `T'
¨': No such file or directory
root@smith:~# PuTTYPuTTYPuTTYPuTTY
-bash: PuTTYPuTTYPuTTYPuTTY: command not found
-> Strange, after executing the command, it puts Putty.... on a new line and
tries to execute it (I'm accessing the server via Putty, which shouldn't be
a problem). Anyway, svnlook outputs very strange characters!
Maybe, if I set the locale to C?
root@smith:~# export LC_ALL="C"
root@smith:~# svnlook diff /data/svn/newrepos2 -r 1
svnlook: Can't convert string from native encoding to
'UTF-8': ?\176?\1?\136?\141
root@smith:~# PuTTYPuTTYPuTTYPuTTY
-bash: PuTTYPuTTYPuTTYPuTTY: command not found
-> Now there's another error message, but still the strange PuTTYPu...
sequence.
Finally, we try to set the locale to utf8:
root@smith:~# export LC_ALL="en_US.utf8"
root@smith:~# svnlook diff /data/svn/newrepos2 -r 1
svnlook: Valid UTF-8 data
(hex:)
followed by invalid UTF-8 sequence
(hex: c0 74 06 08)
The PuTTYPuTTY sequence is gone, but still nothing's working.
What can I do?
Received on Mon Jun 19 09:15:06 2006