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