Do anyone here have the experience with 64bits compiled Samba on SPARC?
Jiri Sasek - Solaris Prague
jiri.sasek at oracle.com
Thu Nov 26 14:49:49 UTC 2015
Your guessing was more accurate than my (exact :-) ) looking into mdb
and your patch eliminated the core-dumps ...seems finally.
Thank you very much,
On 11/26/15 11:21, Ralph Boehme wrote:
> On Thu, Nov 26, 2015 at 06:20:40AM +0100, Jiri Sasek - Solaris Prague wrote:
>> Hi geeks,
>> I have built 64bits Samba and winbindd is receiving the SIGBUS(*)
>> libsmbconf.so.0`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
>> libdbwrap.so`db_rbt_traverse_internal+0x198:jmpl %l3, %o7
>> 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.
> I don't think it's state->private_date, I guess it's value.dptr. Can
> you please test attached patch?
More information about the samba-technical