84165 - Getting "Unaligned access..." messages while trying to bring up mozilla.

Status: RESOLVED DUPLICATE of bug 85890

(SeaMonkey :: General, defect)

Description

[Shanmugavelu Shanmuganathan (gone)]

From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; OSF1 V5.0 alpha)
BuildID:    20010604

When I try to run the binary "mozilla" I get lots of 
"Unaligned access pid=390809 <mozilla-bin> ..." messages.
This causes a lot of delay and the resulting browser
looks like it is hanging. This happend since June 4th build.
It was working fine before that.

Reproducible: Always
Steps to Reproduce:
1. Run "mozilla".
2.
3.

Actual Results:  The mozilla binary prints "Unaligned access pid=390809
<mozilla-bin> ..." messages. And it takes a lot of time (close to 20 minutes)
only to bring a browser which looks like hanging.

Expected Results:  The mozilla browser should have come up.

The  error messages look like 

Unaligned access pid=390809 <mozilla-bin> va=0x1408d36cc pc=0x3000d32b168
ra=0x3000d33a070 inst=0xa4100018
Unaligned access pid=390809 <mozilla-bin> va=0x1408d34cc pc=0x3000d33a074
ra=0x3000d33a070 inst=0xa6940018
Unaligned access pid=390809 <mozilla-bin> va=0x1408d3494 pc=0x3000d32b160
ra=0x3000d33a070 inst=0xa6100008

Comment 1

[Arthur]

This could be the result of a type conversion which isn't allowed on alpha's and
other platforms. For example things like this (from Suse support database):

long *l;
 l = (long *) malloc(sizeof(long)+8);
 printf("address of l (aligned) : %x\n",l);
 ((char *)l)+=3;
 printf("address of l (unaligned) : %x\n",l);

You may not access adresses which are in between the size of a variable.

There are some people working on a patch for gcc which should fix this. Fixing
the code in mozilla is probably easier.

Comment 2

[Jim Dunn]

reassigning

Comment 3

[Shanmugavelu Shanmuganathan (gone)]

Attachment: Fix for 84165 (Unaligned access error on Tru64 UNIX)

Comment 4

[Shanmugavelu Shanmuganathan (gone)]

The  cause for this problem is that some of the variables are 
aligned  on a four byte of memory. 

561   // Round size to multiple of 4 
562   aSize = PR_ROUNDUP(aSize, 4); 

While it should have been aligned on an 8 byte boundary for 
Tru64 UNIX to work.  Now changing the 4 to 8 make the 
problem go away in Tru64 UNIX, and I believe it is harmless 
for other OSs also

Comment 5

[Shanmugavelu Shanmuganathan (gone)]

Chris suggested the following

- you'll need to figure out some clever pre-processor magic to
  compute ALIGN_SHIFT, or...

- look around in the NSPR header files; some of these constants
  may be defined there for you.

I got one in the configuration file under the dir 
/mozilla/nsprpub/pr/include/md

#define PR_BITS_PER_BYTE_LOG2   3

Does it make sense to use this constant in the place of ALIGN_SHIFT?

Comment 6

[Chris Waterson]

Here's the deal: I don't think you should unilaterally change the alignment to 
be 8-byte. It will burn a word on 32-bit systems that we don't need to burn.

Could you do this?

#if PR_BITS_PER_WORD == 64
#  define ALIGN_SHIFT 3
#  define ALIGN_SIZE  8
#elif PR_BITS_PER_WORD == 32
#  define ALIGN_SHIFT 2
#  define ALIGN_SIZE  4
#else
#  error "unimplemented word size"
#endif

Alternatively, you could do something a bit more obtuse:

#define ALIGN_SHIFT (PR_BITS_PER_WORD_LOG2 - 3)
#define ALIGN_SIZE  (1 << ALIGN_SHIFT)

(I think, double-check my math.)

Comment 7

[Shanmugavelu Shanmuganathan (gone)]

Attachment: Using the PR_BITS_PER_WORD to determine the ALIGN_SIZE and ALIGN_SHIFT.

Comment 8

[Chris Waterson]

Looks good to me. ``Beard said 8 was safer than 4'' probably because that
ensures that any doubles get properly aligned. Do we need to worry about this?
If so, maybe using PR_BITS_PER_DOUBLE would be safer than PR_BITS_PER_WORD.
cc'ing beard and brendan, who love to bit twiddle.

Comment 9

[Shanmugavelu Shanmuganathan (gone)]

PR_BITS_PER_DOUBLE is 64 on all platforms. This will force 
the ALIGN_SIZE to be 8 on all platforms. 

Comment 10

[Chris Waterson]

Well, so maybe my original objection (alignment, wasted word) was moot! :-)
Anyway, I think using the mnemonics is better that hard-coding ``8''. Anyway,
I'll let beard and/or brendan comment on the alignment issue.

Comment 11

[Jim Dunn]

Ok, so can we get a review for the latest patch
(Created an attachment (id=39266)) for the trunk
and the branch?  Shanmu can then go ask 
[e-mail] for approval and hopefully we can
get this checked in.

Comment 12

[Chris Waterson]

Please run iBench and jrgm's page loader tests to verify that there are no
performance problems introduced by this change (the math look good to me, but
I've seen stranger things happen). Do that, and r=waterson

Comment 13

[Jim Dunn]

so we need to test a linux build with and without this patch...
and make sure we don't impact performance:

goto: http://dogspit.mcom.com/ibench/testlist/home_js.asp

and to be REALLY careful... it will be good to test
John Morrisson <[e-mail]>'s
<http://cowtools.mcom.com/>

thanks for the pointers chrisW

Comment 14

[John Morrison]

Okay, left hand, say hello to the right hand. 

This bug is also being dealt with as bug 85890, which has a patch, which is 
already checked inot the branch (just now), but it's not the same patch. 
Let the bit-twiddlin wars begin ...

Comment 15

[Marc Attinasi]

Ack! The patch from bug 85890 is now checked into both branch and trunk. Check
it out - it may be good enough, maybe not - you decide.

Comment 16

[Jim Dunn]

This is a dup of 85890, the fix checked in, fixes this.
closing this out.

*** This bug has been marked as a duplicate of 85890 ***