mnesia disc_copies memory size corrupts w/HiPE 64-bit

Paul Fisher pfisher@REDACTED
Thu Aug 20 01:53:28 CEST 2009


I have a mnesia table that is defined as disc_copies, which ends up with 
a corrupt memory size value after being updated from concurrent (erlang) 
processes from code compiled with HiPE.  All updates to the table are 
done as mnesia:transaction/1 calls.

If I update the table from only two processes the memory size is correct:

(emacs@REDACTED)2> mnesia:table_info(clu_unassignedq,size).
0
(emacs@REDACTED)3> mnesia:table_info(clu_unassignedq,memory).
90

After updating the table via 11 processes, the table size ends up zero, 
but memory size is completely bogus:

(emacs@REDACTED)10> mnesia:table_info(clu_unassignedq,size).
0
(emacs@REDACTED)11> mnesia:table_info(clu_unassignedq,memory).
2305843009213693459

If the same thing is done with the code calling the mnesia operations is 
*not* compiled with HiPE, all is well and everything appears correct.

This appears to be an artifact of the SMP/ets concurrency improvements 
introduced in R13. Thoughts for further investigation?

Platform is amd64 (intel core 2) on opensolaris.  Erlang R13B02 snapshot 
from 2009/08/12.

pfisher@REDACTED:~/lm/third_party/erlang-R13/install/solaris$ gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure 
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld 
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)


--
paul


More information about the erlang-bugs mailing list