Re: fix for spread-4.4.0 crash in mixed endian environment

Yes, that is definitely a bug and your fix looks correct.  I apologize, we =
need to do better mixed endian testing on our end.

With this fix, does Spread now function as expected for you?

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200

On Sep 10, 2014, at 8:52 AM, Martin Schu <[email protected]> wrote:

We have some SPARC and some Intel hosts running spread-4.1. Everything was =
working fine with spread-4.1 in that mixed endian environment.

After upgrading from spread-4.1 to spread 4.4.0 we observed problems when s=
pread-4.4 daemons are started on both SPARC(Solaris) and Intel(RHEL). Every=
thing is working fine as long as the spread-4.4 daemons are started *only* =
on SPARC hosts or *only* on Intel hosts.

Now we first start all spread daemons on Intel. When the first daemon of th=
e =93other endian=94 architecture is run up problems begin. We found the fo=
llowing alarm message in a spread logfile. And a spread daemon was crashing=
 with core dump.

2014-09-08 17:43:59 GMT Prot_handle_bcast: invalid packet with seq -1062731=
160 from 21, processed bytes not equal data_len 16905 1395

The program code emitting that alarm is new since spread-4.3. It is only re=
levant in mixed endian environments.

Obviously something is wrong with the length calculation. The length report=
ed in the alarm message (16905) is far away from the desired value 1395.

We believe there is a bug in the pointer calculation of the frag_ptr in pro=
tocol.c. Below a proposed patch for that.
Can you confirm this?
We would be glad if that could be included in a future release of spread. =


Kind regards,
Martin =


--- daemon/protocol.c.orig         2014-05-15 17:04:35.000000000 +0200
+++ daemon/protocol.c 2014-09-09 14:37:40.845240310 +0200
@@ -409,7 +409,7 @@
                                        pack_ptr->transmiter_id, pack_ptr->=
seq, processed_bytes, pack_ptr->data_len );
                                 break;
                         }
-                        frag_ptr =3D (fragment_header *) &pack_body_ptr[pr=
ocessed_bytes];
+                        frag_ptr =3D (fragment_header *) (((char*)pack_bod=
y_ptr) + processed_bytes);
                         Flip_frag(frag_ptr);
                         processed_bytes +=3D sizeof(fragment_header) + fra=
g_ptr->fragment_len;
                 }