Mnesia deadlock?

[Rudolph van Graan]

Hi Adam,

Haven't spoken to you for a while...!

We have an internal rule that it is illegal to have *any* side  
effects apart from mnesia calls inside the transaction funs. Side  
effects include:

1. Sending/receiving messages
2. Any socket calls
3. Any file accesses
4. Any calls to gen_server processes
5. Any ets/dets calls etc

Also look for nested transactions (dirty access context over  
syncronous transactions access contexts) etc. They can crash mnesia  
big time.

We have been bitten a number of times by caused by side-effects which  
by nature is very difficult to trace. Symptoms include infinite  
recursions, deadlocks, hangs etc etc. Nasty stuff.


A good rule of thumb is to think what will happen when the  
transaction fun is executed more than once. Will it change the  
result? If so, you have side effects.

Regards,

Rudolph

On 02 Jan 2006, at 1:36 PM, Adam Aquilon wrote:

>
> 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
>
>
>