Mnesia deadlock?

[Adam Aquilon]

Thank you Dan and Klacke!
We're currently looking at both using R10 and finding any potential
deadlocks in transactions. See below for comments:


Dan Gudmundsson wrote:
...
> Oh No, don't use 4.1.12 (precompiled) and don't use the compiler from
> that release, that compiler produced broken code on mnesia_tm which
> wrote garbage on the heap (or somewhere else) which could
> cause really
> strange problems.
> 
> Try upgrading compiler, recompile mnesia and try again.
> 
> Other than that mnesia have had a couple fixes since 4.1.12 :-)
> it could be worth upgrading to something later.
> 
> Nowadays the compiler have an inbuilt beam validator that checks that
> the produced code don't have such problems anymore.
> 
> /Dan

Thanks for the tip!

We haven't upgraded before because of some extra packages that we
must compile into the release (we make our own RPM's) which is a
bit of a bother. Also, "the devil you know" is better than new,
uncharted functionality when it comes to releases.

But now it seems that it is time to start using R10 after all.


Klacke wrote:
...
> So - tip no 1, check for gen_server:calls inside your transactions.
> Look closely on your user process (i.e <0.932.1> )
> and figure our what it's waiting for and why. What's the message
> in the queue for that process !!! very suspicious.
...

Unfortunately the VM ran out of memory during sunday morning and
was autorestarted, so I can no longer examine the processes again
without forcing another hang.

I checked the crash dump and there weren't very many processes in
the system, around 2300. Granted, this is more than normal, but not
an enormous amount. This indicates that some process(es) were eating
large gobs of heap space. 

Doesn't this speak against having a pure deadlock situation?

(We are looking for receive stuff inside transactions anyway, just
to be sure.)

/Adam