fix for spread-4.4.0 crash in mixed endian environment

--===============3106192267358634672==
Content-Type: multipart/alternative; boundary=047d7b6d84e24c91f40502b587c6

--047d7b6d84e24c91f40502b587c6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
spread-4.4 daemons are started on both SPARC(Solaris) and Intel(RHEL).
Everything 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
the =E2=80=9Cother endian=E2=80=9D architecture is run up problems begin. W=
e found the
following 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
-1062731160 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
relevant in mixed endian environments.

Obviously something is wrong with the length calculation. The length
reported 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
protocol.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[processed_bytes];
+                        frag_ptr =3D (fragment_header *)
(((char*)pack_body_ptr) + processed_bytes);
                         Flip_frag(frag_ptr);
                         processed_bytes +=3D sizeof(fragment_header) +
frag_ptr->fragment_len;
                 }

--047d7b6d84e24c91f40502b587c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We have some SPARC and some Intel hosts running spread-4.1=
. Everything was working fine with spread-4.1 in that mixed endian environm=
ent.<br><br>After upgrading from spread-4.1 to spread 4.4.0 we observed pro=
blems when spread-4.4 daemons are started on both SPARC(Solaris) and Intel(=
RHEL). Everything is working fine as long as the spread-4.4 daemons are sta=
rted *only* on SPARC hosts or *only* on Intel hosts.<br><br>Now we first st=
art all spread daemons on Intel. When the first daemon of the =E2=80=9Cothe=
r endian=E2=80=9D architecture is run up problems begin. We found the follo=
wing alarm message in a spread logfile. And a spread daemon was crashing wi=
th core dump.<br><br>2014-09-08 17:43:59 GMT Prot_handle_bcast: invalid pac=
ket with seq -1062731160 from 21, processed bytes not equal data_len 16905 =
1395<br><br>The program code emitting that alarm is new since spread-4.3. I=
t is only relevant in mixed endian environments.<br><br>Obviously something=
 is wrong with the length calculation. The length reported in the alarm mes=
sage (16905) is far away from the desired value 1395.<br><br>We believe the=
re is a bug in the pointer calculation of the frag_ptr in protocol.c. Below=
 a proposed patch for that.<br>Can you confirm this?<br>We would be glad if=
 that could be included in a future release of spread. <br><br>Kind regards=
,<br>Martin <br><br><span style=3D"font-family:courier new,monospace">--- d=
aemon/protocol.c.orig =C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-05-15 17:04:35.00000=
0000 +0200<br>+++ daemon/protocol.c 2014-09-09 14:37:40.845240310 +0200<br>=
@@ -409,7 +409,7 @@<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 pack_ptr-&gt;transmiter_id, pack_ptr-&gt;seq, processed_bytes=
, pack_ptr-&gt;data_len );<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0br=
eak;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0}<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frag_ptr =3D (fragment_header *) &=
amp;pack_body_ptr[processed_bytes];<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frag_ptr =3D (fragment_hea=
der *) (((char*)pack_body_ptr) + processed_bytes);<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Flip_f=
rag(frag_ptr);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0processed_bytes +=3D sizeof(fragment_head=
er) + frag_ptr-&gt;fragment_len;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0}<br><br></span></div>

--047d7b6d84e24c91f40502b587c6--


--===============3106192267358634672==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Spread-users mailing list
[email protected]
http://lists.spread.org/mailman/listinfo/spread-users

--===============3106192267358634672==--