Do anyone here have the experience with 64bits compiled Samba on SPARC?

Jiri Sasek - Solaris Prague jiri.sasek at
Thu Nov 26 05:20:40 UTC 2015

Hi geeks,

I have built 64bits Samba and winbindd is receiving the SIGBUS(*)

...on:`talloc_dict_traverse_fn+0xf0:   ldx [%l2], %l3

where l2 is equal to 2b50c7275c as can be seen from stackregs trace:
fffffdfa7f401190, fffffdfa7f400bf8, fffffdfa7f400bd8, 1, fffffdfa7f400c20)
   %l0-%l3:    7ffc619014800               44 2b50c7275c               44
   %l4-%l7:       2b50c72718               44 2b50c72718               44`db_rbt_traverse_internal+0x198:jmpl %l3, %o7

> 2b50c7275c,10::dump
               0 1 2 3  4 5 6 7  8 9 a b \/ d e f 0123456789abvdef
2b50c72750:  00000000 00000000 00000000 0000002b ...............+
2b50c72760:  50c73170 000a8750 0000002b 50c72500 P.1p...P...+P.%.

So I suppose the problem is the 0x2b50c7275c address is not the 64bits 

I have also localized the problem is (with some [RISC optimized code] 
uncertainty :-) ) in samba-4.1.17/source3/lib/talloc_dict.c 
(talloc_dict_traverse_fn) line:

148	return state->fn(data_blob_const(key.dptr, key.dsize),
149			 *(void **)value.dptr, state->private_data);

3-rd parameter eveluation:

state->private_data  ...dereferencing.

Many thanks for any suggestions,
(lazy Jeremy says :-) ) Jiri

(*) - SIGBUS is an exception generated when data pointer is misaligned 
mainly used on RISC platforms.
  note: Intel can workaround such misalignment by spending several more 
CPU cycles as a cache penalty on instruction execution.

More information about the samba-technical mailing list