[erlang-bugs] Unloading then reloading crypto.so causes erlang core dump on Solaris 11

[XinFeng Liu]

Hi,
I'm trying CouchDB (version 1.2) on Solaris 11 Sparc, but running CouchDB
testsuite in browser caused erlang process core dumped. I tried both erlang
14B04 and 15B01.
After investigation, I found it occurred when couchDB restarted itself.
During restarting, erlang unloaded crypto.so then reloaded it into a
different address, but openssl library libcrypto.so still using the old
call back address of  crypto_alloc() in lib/crypto/c_src/crypto.c. In fact,
crypto_alloc() is shown as a local function from "nm" command.

The temporary workaround is modifying crypto.c:
replace   CRYPTO_set_mem_functions(crypto_alloc, crypto_realloc,
crypto_free);
to:
             CRYPTO_set_mem_functions(enif_alloc, enif_realloc, enif_free);

I'm not sure it is erlang bug or bug of openssl  for solaris, please help
clarify?

The detailed logs are below:
====================

core dump stack (using Solaris mdb utility):
------------------------
ffbff038 0xfe7e6c48(64, fcd77cc4, ce, fcd96000, fcc53a18, 400)   <=====
illegal address of function
ffbff098 libcrypto.so.1.0.0`EVP_DigestInit_ex+0x1d8(ffbff20c, fcda3218,
1e000,
d000, ae124, d218)
ffbff0f8 libcrypto.so.1.0.0`ssleay_rand_bytes+0x360(4c84e4, 3, 2784, 7b,
fcd98770, 2400)
ffbff228 libcrypto.so.1.0.0`ssleay_rand_pseudo_bytes+8(4c84e4, d, ffbff2e8,
0, 0
, fccdde58)
ffbff288 crypto.so`rand_bytes_1+0x2c(ffbff3a4, 1, 46ce00, 4c84a1, 46ce00,
8)
ffbff2f0 process_main+0x33a0(1f3110, 46de40, 46ce00, 46ce00, fef35440,
555440)
ffbff3e0 erl_start+0x4a4(17d4d0, ffbff7ac, 17d6a8, 0, 0, ffbff97a)
ffbff6e8 main+0xc(0, ffbff7ac, ffbff838, 1f3510, 0, ff0e0180)
ffbff748 _start+0x5c(0, 0, 0, 0, 0, 0)

Before core dump, 0xfe7e6c48 was:
> 0xfe7e6c48::dis
crypto.so`crypto_alloc:         or        %o7, %g0, %g1

Before core dump, crypto.so was loaded to the address starting 0xfe7e0000 :
> ::mappings!grep crypto
fcc00000 fcd86000   186000 /lib/libcrypto.so.1.0.0
fcd96000 fcda8000    12000 /lib/libcrypto.so.1.0.0
fcdb0000 fcdb4000     4000 /lib/libcrypto.so.1.0.0
fe7e0000 fe7e8000     8000
/opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so
fe7f6000 fe7fa000     4000
/opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so

After reloading crypto.so, it was loaded to the address starting 0xfef30000
:
> ::mappings!grep crypto
fcc00000 fcd86000   186000 /lib/libcrypto.so.1.0.0
fcd96000 fcda8000    12000 /lib/libcrypto.so.1.0.0
fcdb0000 fcdb4000     4000 /lib/libcrypto.so.1.0.0
fef30000 fef38000     8000
/opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so
fef46000 fef4a000     4000
/opt/local/lib/erlang/lib/crypto-2.1/priv/lib/crypto.so

And the old address of crypto.so (0xfe7e0000 to fe7fa000) was unmapped:
...
fe78c000 fe78e000     2000 /lib/libnvpair.so.1
fe7d0000 fe7d2000     2000
fe800000 fe810000    10000
fe820000 fe822000     2000
fe830000 fe840000    10000 /usr/lib/libidmap.so.1
...

Thanks,
Xinfeng Liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120905/c2426063/attachment.htm>