[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

798.0. "Unaligned data access warning on MIPS. (PMAX)." by 45830::CURLEY (Dave Curley, IED/Reading, DTN 830-4354) Thu May 18 1989 06:27

    I'm porting some code onto MIPS/ULTRIX that I know works on both
    platforms on VAX.
    
    I'm getting a series of messages like:
    
    Fixed up unaligned data access for pid 18599 (demo) at pc 0x480440
    
    I'm told the primary cause of this is structure members allocated
    on uneven word boundaries.    However I've checked all my structures
    and they only have 32-bit members (ints and char *'s).
    	I also tracked some of the messages as far as I could using dbx, and
    they're being issued while DECwindows toolkit code is being executed.
    Specifically, inside a subroutine of DwtDrmHGetIndexedLiteral. I
    also call this routine elsewhere in my code, and that's okay.
    
    Can anyone give me any suggestions, or even shed light on whether
    it's still likely to me me rather than the toolkit that's causing
    the messages ?
    
    Thanks,
    
    Dave
    
    
    BTW. The program still works fine, it just issues ugly (and worrying)
    messages.
    

T.RTitleUserPersonal
Name
DateLines
798.1FLUME::dikeThu May 18 1989 10:048
I have seen unaligned accesses when a caller and callee disagree
about the size of a parameter, for example, I saw this when calling
XTranslateCoordinates with pointers to shorts instead of pointers
to ints.  However, the only parameter that seems suspicious in your
case is the context_id and I don't know enough to say whether that
could be the cause.
				Jeff

798.2More confused now45830::CURLEYDave Curley, IED/Reading, DTN 830-4354Thu May 18 1989 11:1313
    Jeff,
    
    	I don't understand...
    
    	Aren't pointers the same size regardless of whether they
    point to ints or shorts ?    Or am I being silly ?
    
    	I just ran a program on MIPS to print sizeof() for an int *,
    and for a short *, and got 4 for both.
    
    Dave
    

798.3Why not a toolkit problem?TLE::D_SMITHThu May 18 1989 12:218
    Isn't it possible that the resource manager has a structure which does
    not have fields on "natural" boundaries?  I just had a look at one of
    the DRM include files from around last June and one of the structures
    was declared with a short int followed by a character pointer.  If I
    understand the data types correctly a short int is 16 bits while a
    character pointer is 32.  This would result in the address fixup. 
    Perhaps one of the toolkit people should have a look.

798.4Its not a toolkit problem.56579::thomasThe Code WarriorThu May 18 1989 12:3128
The most common way of getting unaligned access errors is

   Calling DwtGetNextSegment with a dirRtoL declared as a boolean.  The routine
   itself declares dirRtoL as a int *.

   Having pointer dereferences like *(int *)p (where int could be short or
   a struct tag * as well) and p is char *.

To find out where it is happening, use dbx.  For instance:

Fixed up aligned access for pid 1110 (hpwm) at pc 0x44b820.
% dbx hpwm
[...]
(dbx) 0x44b810/10i
  [XQueryPointer:176, 0x44b810]         lw      r14,96(sp)
  [XQueryPointer:176, 0x44b814]         lh      r13,60(sp)
  [XQueryPointer:176, 0x44b818]         nop
  [XQueryPointer:176, 0x44b81c]         sw      r13,0(r14)
  [XQueryPointer:184, 0x44b820]         lw      r24,100(sp)
  [XQueryPointer:184, 0x44b824]         lh      r15,62(sp)
  [XQueryPointer:184, 0x44b828]         nop
  [XQueryPointer:184, 0x44b82c]         sw      r15,0(r24)
  [XQueryPointer:192, 0x44b830]         lw      r8,104(sp)
  [XQueryPointer:192, 0x44b834]         lhu     r25,64(sp)

So obviously hpwm has a problem calling XQueryPointer.


798.5But that suggests the toolkit45830::CURLEYDave Curley, IED/Reading, DTN 830-4354Thu May 18 1989 13:1819
    Ok, I did that to track down the source of the problem originally,
    and the subroutine I mentioned in .0 is what I arrived at.
    
    Here's my version of the dbx dump, but I'm still unclear on whether
    it's MY fault or not, as I'm not passing any strange arguments:
    
      [DwtIdb__DB_GetDataEntry:198, 0x48b700]       addiu   r17,r17,16
      [DwtIdb__DB_GetDataEntry:189, 0x48b704]       ori     r21,r21,0x88ae
      [DwtIdb__DB_GetDataEntry:199, 0x48b708]       beq     r8,r21,0x48b748
      [DwtIdb__DB_GetDataEntry:199, 0x48b70c]       nop
      [DwtIdb__DB_GetDataEntry:202, 0x48b710]       lui     r4,0x1002
      [DwtIdb__DB_GetDataEntry:202, 0x48b714]       lui     r5,0x1002
      [DwtIdb__DB_GetDataEntry:202, 0x48b718]       li      r9,26
      [DwtIdb__DB_GetDataEntry:202, 0x48b71c]       sw      r9,16(sp)
      [DwtIdb__DB_GetDataEntry:202, 0x48b720]       addiu   r5,r5,21328
      [DwtIdb__DB_GetDataEntry:202, 0x48b724]       addiu   r4,r4,21304
      
    Dave

798.6What the address of the unaligned access?56579::thomasThe Code WarriorThu May 18 1989 16:082
Looking at the routine, it might be possible but it doesn't look probable.