However, on this one machine, I get:
# cd /opt/subversion/bin
# ./svn --version
Segmentation fault(coredump)
# dbx svn core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
Segmentation fault in check_sbcs at 0xd1a85f14 ($t1)
0xd1a85f14 (check_sbcs+0x104) 80630010 lwz r3,0x10(r3)
(dbx) quit
#
And for the life of me, I can not work out what the differences are.
Has anyone else seen the same error.
It's been fixed in later versions of apr_util, but that does not
explain _why_ it works on _some_ machines but not this one.
This one's driving me nuts.
-Chris
It's definately looking as though TL11 is at fault
oslevel -s output:
Initial Install - 5300-00-0000
svn --version: works
TL8
svn --version: works
TL10 - 5300-10-01-0921
svn --version works.
TL11 - 5300-11-00-0000
svn --version coredumps.
About to try SP1.
This is a 9114-275 machine, 2Gb ram, base AIX OS and the Subversion
1.4.6 tarball unpacked and nothing else.
If SP1 doiesn't fix it, I'm thinking it's PMR time... :-)
-Chris
TL11-SP1 - 5300-11-01-0944
svn --version coredumps :-(
So it's looking like bos.rte.iconv 5.3.11.0 is the offending artefact.
-Chris
The ugliest of all hacks:
cd /usr/lib
cp libiconv.a libiconv.a.TL11
cp /tmp/libiconv.a libiconv.a.TL10
ln -sf libiconv.a.TL10 libiconv.a
svn --version no longer core dumps...
:-)
So I wonder what the APAR details that caused a change to libiconv.a
where?
-Chris
At least it appears that I am not the only one who is having this
problem with TL11. :-)
See: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413761
After digging a little more, we can see:
Which leads to:
Let's hope they add a regression test for this one.
-Chris
cheers - moved my SVN repository to Ubuntu and lots of tar/scp/tar/svn
add/imports