Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 4281 - Structure assignment with increment problem
Summary: Structure assignment with increment problem
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: egcs
Version: 6.0
Hardware: sparc
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-31 02:21 UTC by Jeff Johnson
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-08-02 19:09:47 UTC

Attachments (Terms of Use)

Description Jeff Johnson 1999-07-31 02:21:12 UTC
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.

Comment 1 Jim Kingdon 1999-07-31 21:14:59 UTC
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.

Comment 2 Jeff Johnson 1999-07-31 22:56:59 UTC
*** 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:
--- dump-0.4b4/compat/include/pathnames.h.0
+++ dump-0.4b4/compat/include/pathnames.h
@@ -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.

Comment 3 Jeff Johnson 1999-07-31 22:58:59 UTC
Please disregard the wrong duplicate (fat fingers).

Comment 4 Jeff Johnson 1999-08-02 15:32:59 UTC
I believe I've verified this on alpha egcs also.

Comment 5 Jim Kingdon 1999-08-02 19:09:59 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.