klr@hadron.UUCP (Kurt L. Reisler) (07/20/89)
OK, this is a new to me. Have been moving a variety of programs from an
Ultrix 2.3 environment on a VS2000 (using X11.3) to a DS3100 and Ultrix
3.0 (and a mix of DECWindows and X 11.3) and I am coming up with the
following error messages when certain programs (which compile and
otherwise run flawlessly):
"Fixed up unaligned data access for pid XXXXXXX (proc_name) at pc 0xNNNNNN"
These message come out on stderr at sporatic intervals when programs
such as dtree are run. The program run fine otherwise.
Any suggestions as to what is going on, and what might be able to be
done to eliminate the problem, other than diverting stderr to /dev/null.
Thanks in advance.
Kurt Reisler (703) 359-6100
============================================================================
UNISIG Chairman, DECUS US Chapter | Hadron, Inc.
..{uunet|sundc|rlgvax|netxcom|decuac}!hadron!klr | 9990 Lee Highway
Sysop, Fido 109/101 The Bear's Den (703) 671-0598 | Suite 481
Sysop, Fido 109/103 The Pot of Gold (703) 359-6549 | Fairfax, VA 22030
============================================================================chris@winsrf.dec.com (Chris Cordrey) (07/21/89)
In article <861@hadron.UUCP>, klr@hadron.UUCP (Kurt L. Reisler) writes: > OK, this is a new to me. Have been moving a variety of programs from an > Ultrix 2.3 environment on a VS2000 (using X11.3) to a DS3100 and Ultrix > 3.0 (and a mix of DECWindows and X 11.3) and I am coming up with the > following error messages when certain programs (which compile and > otherwise run flawlessly): > > "Fixed up unaligned data access for pid XXXXXXX (proc_name) at pc 0xNNNNNN" > > These message come out on stderr at sporatic intervals when programs > such as dtree are run. The program run fine otherwise. > > Any suggestions as to what is going on, and what might be able to be > done to eliminate the problem, other than diverting stderr to /dev/null. see nac(1) for more info on how to shut off the messages. Those "annoying" messages are coming from the Ultrix Kernel which has added support on the DECstation to catch unaligned data accesses and fix them dynamically for your program and let it continue running (an obvious performance hit which you can fix by aligning the offending variables in your source - the trick is finding them!) VAXen are more forgiving in this area. The DECstation 3100 assumes that ints and pointers are aligned on longword (4byte) boundaries and that shorts are aligned on halfword (2byte) boundries. Here's an example of unaligned data you can try on your 3100. unaligned.c -------------------- main() { short a = 1; short b = 2; printem(&a,&b); } printem(x,y) int *x; int *y; { printf("%d %d\n",*x,*y); } ----------------------- Hope this helps, chris
dbb@riscy.dec.com (David Barrett) (07/21/89)
> OK, this is a new to me. Have been moving a variety of programs from an > Ultrix 2.3 environment on a VS2000 (using X11.3) to a DS3100 and Ultrix > 3.0 (and a mix of DECWindows and X 11.3) and I am coming up with the > following error messages when certain programs (which compile and > otherwise run flawlessly): > > "Fixed up unaligned data access for pid XXXXXXX (proc_name) at pc 0xNNNNNN" On VAXen, short words or longs can be accessed on any byte boundary, however, on RISC systems references must be "naturally aligned". Short words (2 bytes) must be on an even byte boundary, while long words must be accessed on a boundary evenly divisible by 4. Unaligned accesses in programs cause a trap into the kernal, which attempts to "fixup" the unaligned access. If the system is able to perform the fixup, the above "fixed up" message is printed to stdout. If the system is unable to fixup the unaligned access, the process will be terminated with a SIGBUS (bus error) signal. This process has a definite performance impact, so performing the alignment in your code is recommended. ---------------------------------- David Barrett UUCP: ...!decwrl!riscy.dec.com!dbb Digital Equipment Corporation New York ULTRIX Resource Center INET: dbb%riscy.dec@decwrl.dec.com
michaud@decvax.dec.com (Jeff Michaud) (07/21/89)
In article <2678@decuac.DEC.COM>, chris@winsrf.dec.com (Chris Cordrey) writes: > > "Fixed up unaligned data access for pid XXXXXXX (proc_name) at pc 0xNNNNNN" > see nac(1) for more info on how to shut off the messages. That should be uac(1). There is also a system call you can use to change it though I forget it's name at this time (it may be a syscall(2)). > (an obvious > performance hit which you can fix by aligning the offending variables > in your source - the trick is finding them!) Finding them is pretty easy. dbx the offending program, then dbx> 0xNNNNNN/10i will tell you the routine-name:linenumber of the offending source line. > VAXen are more forgiving in this area. Yes, but you take the performance hit in the microcode instead :-) -- /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
steve@vorga.umiacs.umd.edu (Steve D. Miller) (07/21/89)
Does turning off the messages also turn off the fixups? Is there any way to turn off the fixups, either on a per-process or systemwide basis? -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
michaud@decvax.dec.com (Jeff Michaud) (07/22/89)
In article <18664@mimsy.UUCP>, steve@vorga.umiacs.umd.edu (Steve D. Miller) writes: > Does turning off the messages also turn off the fixups? Is there any way > to turn off the fixups, either on a per-process or systemwide basis? Turning off the messages only turns off the message going to the users terminal (ie. the uprintf's). They still go to the error logger (which can be looked at using uerf) so its a double performance killer, once for the fixup, and again because it has to log it through the error logging daemon. uac(1) can turn off the message on a per-process or systemwide basis. Turning it off for a process also turns it off for children of the process. Unaligned accesses are really bugs in the application. It is just that so maney of us have been spoiled by the VAX in being able to cast pointers to pointers to anything we like :-). Kernel hackers note that unaligned accesses in the kernel result in a panic (ie. no fixups in kernel mode). -- /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/