[erlang-bugs] segmentation fault in tree_delete at beam/erl_bestfit_alloc.c:431
Igor Goryachev
igor@REDACTED
Mon Mar 21 19:46:40 CET 2011
Hi, Patrik.
On Fri, Mar 18, 2011 at 12:49, somebody wrote:
> First of all, I have to ask if you have some non-OTP drivers or NIF's
> loaded in the VM? Have you loaded some native code not supplied in the
> Erlang distribution? In that case, try to rule out errors in that code
> and in libraries loaded by that code by e.g. disabling it in some way
> (write slower erlang-replacements etc).
We have pair of nodes per machine which are sort of frontend/backend
and are speaking with each other using standard erlangish rpc. Frontend
node (the one which segfaults) uses exmpp library by ProcessOne. Other
third parties libraries (and my own code) do not contain non-OTP linked-in
drivers and NIF's.
> Next question is if you use some drivers or NIF's provided by us that
> pull third party libraries, like Wx oc Crypto (by using SSL etc). If
> we could isolate the problem to a driver (our's or your's) the
> searchspace would be greatly reduced.
We have no encryption here, but crypto application is loaded only for
sha/1 usage. No wx, etc...
> Also, looking at the core locally would possibly help me to identify
> the type of data that has been written into the block, which possibly
> could narrow it down, so if you could tar your compiled build tree and
> the core and put it on something where I can fetch it (mail me
> personally with the details, if you can do that), that would be
> helpful.
Ok, I will prepare a tarball as soon as possible and send you a link.
> You say this is frequent. Is it in any way manually reproducable? Have
> you got any idea of which erlang-code is run when this happens
> (i.e. during some special kind of workload)? One possibility is that
> this is a compiler error (in our compiler that is), so a module
> triggering the proble m would also be interesting.
It occurs two-three times during a day time. For now I have no idea how
it could be reproduced manually.
> Please make sure to run R14B02 and recompile all erlang code with the
> latest Erlang version to rule out any bug that's already corrected :)
Yes, I have already installed R14B02, but behaviour is the same.
> Sorry for the big fluffy list of options, but as I said, this is a
> kind of error that is really hard to track down...
Thank you very much for your answer. I hope we resolve this issue. :-)
--
Igor Goryachev
More information about the erlang-bugs
mailing list