[CMake] SEGV and signal BUS with cmake-2.8.11 on Solaris 10

[Rolf Eike Beer]

Bill Hoffman wrote:
> On 5/22/2013 3:58 PM, Rolf Eike Beer wrote:
> > This isn't entirely unexpected:
> > 
> > http://open.cdash.org/viewBuildError.php?type=1&buildid=2912493
> 
> Anybody have suggestions for a fix?   This code was taken from here:
> http://www.aarongifford.com/computers/sha.html
> 
> Is there a way to get a struct like that to align correctly?  Maybe make
> it a union with something that is the same number of bytes in 64 bit types?

If I look at the cast warning I think most of them are actually not true. Take 
for example this one:

	sha_word64	T1, T2, *W512 = (sha_word64*)context->s512.buffer;

The buffer is aligned to the end of the previous entry in the struct, which is 
an uint64, so this is no problem. It could be if someone would take arbitrary 
memory, and cast something unaligned to that struct and then use it, but that 
is not done.

What is likely the problem of that crash is line 1428 in SHA512_Update():

		SHA512_Internal_Transform(context, (sha_word64*)data);

This will use a user-supplied data buffer, which may have any possible 
alignment because it maybe just any string.

I think that this should fix the problem:

diff --git a/Source/cm_sha2.c b/Source/cm_sha2.c
index 12c39ed..b52588a 100644
--- a/Source/cm_sha2.c
+++ b/Source/cm_sha2.c
@@ -1425,7 +1425,12 @@ void SHA512_Update(SHA_CTX* context, const sha_byte *data, size_t len) {
        }
        while (len >= 128) {
                /* Process as many complete blocks as we can */
-               SHA512_Internal_Transform(context, (sha_word64*)data);
+               /* Copy this to a buffer of 64 bit base type as the pointer passed in
+                * may have any alignment, but there are platforms that do not allow
+                * unaligned access to 64 bit values. */
+               sha_word64 tmp[128 / sizeof(sha_word64)];
+               MEMCPY_BCOPY(tmp, data, 128);
+               SHA512_Internal_Transform(context, tmp);
                ADDINC128(context->s512.bitcount, 1024);
                len -= 128;
                data += 128;

This shouldn't even hurt performance very much, as it is very likely that the 
buffer will never leave the level 1 cache.

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130525/b90d4d2c/attachment.pgp>