While debugging a dump problem, I found a compiler bug
in egcs-1.1.2-16 on (at least) sparc (an ultra if it
Test program coming by e-mail.
As long as you were compling for sparc32 (which is the default),
it shouldn't matter whether it is an Ultra. Looking forward to
seeing your test case.
*** Bug 3272 has been marked as a duplicate of this bug. ***
Local backups work, but remote backups fail. Consider the
output from the command run on host mowgli, doing a remote
backup to itself: [The outcome is the same when doing this
between different hosts]
/sbin/dump 0f mowgli:/dev/st1 /
DUMP: Date of this level 0 dump: Wed Jun 2 12:03:14 1999
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/sda1 (/) to /dev/st1 on host mowgli
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 62627 tape blocks on 1.61 tape(s).
/sbin/dump: Lost connection to remote host.
DUMP: Bad return code from dump: 1
The problem turns out to be that dump tries to invoke
/sbin/rmt as rmt, but does not find it because /sbin is not
in the default path.
dump envokes rmt using an rcmd call [dumprmt.c line159]. The
argument of the remote program to run is set in
compat/include/pathnames.h line 49 as
#define _PATH_RMT "rmt"
The problem is that the rmt program /sbin/rmt is NOT in the
default path, and so dump connects to a program that does
not exist. Unfortunately, the rcmd call does not fail, nor
does the first write to the pipe opened by the rcmd call.
The first error is encountered when trying to read the reply
from the first write (which is the command to instruct rmt
to open the specified device file). This leads to the very
misleading error message "lost connection" shown above.
Multiple solutions are possible.
1) _PATH_RMT can be defined to be "/etc/rmt" instead of
"rmt". This is the solution used by tar-1.12 to find rmt.
On all the hosts I checked this appears to be a symbolic
link to the real location of rmt [HP-UX, SunOS, Solaris,
Linux/Redhat, Linux/Debian]. The only exception I found was
AIX, and that is just a weird OS anyway. I figure if it is
good enough for tar, it is good enough for me.
2) Change the default path to include /sbin. This way rcmd
will find rmt OK. This does not appear to be a good idea
since it could have a bunch of side effects.
3) Link /sbin/rmt to /bin/rmt or move rmt to the /bin. This
appears to be a good solution but since the /etc/rmt link is
already required for tar, this seems to be a proliferation
of links that is unnecessary.
Any of the above solutions solve the problem, and you could
probably find better ones, but #1 appears to be the
preferred solution. Here is a patch file:
@@ -46,4 +46,4 @@
#define _PATH_DTMP "/etc/dtmp"
#define _PATH_DUMPDATES "/etc/dumpdates"
#define _PATH_LOCK "/tmp/dumplockXXXXXX"
-#define _PATH_RMT "rmt"
+#define _PATH_RMT "/etc/rmt"
It is probably worth adding to the dump docs that the
/etc/rmt linkis needed so that if the remote host is AIX or
something weird that there is a pointer
However, I am concerned that there is a problem somewhere in
the rcmd code that should report the failure earlier on and
somehow does not, leading to the misleading error message.
This is probably worth investigating.
Please disregard the wrong duplicate (fat fingers).
I believe I've verified this on alpha egcs also.
OK, I was able to verify that this test case was generating bad RTL.
Jeff Law's 29 Jun fix to emit_block_move would seem to exactly match
this situation - block moves with a postincrement as an argument.
This is the fix that I already added to egcs-1.1.2-17 as a fix for
bugzilla #3971, and the current (4281) test case works if I use
So in summary: upgrade to egcs-1.1.2-17.