The by far fastest way to handle a bug is of course to fix it and submit a patch. Even a patch that is rudimentary but points out where the faulty code is is better than no patch at all.
The better the problem is isolated and the smaller the test program (or test case) that shows the bug is, the faster it can be fixed. If at all possible, try to write a small program that provokes the bug.
When you have a sufficiently small program or example that shows the bug, send it to the 'erlang-bugs' mailing list, together with the following information:
A description of the bug and any helpful hints that you can think of are also appreciated.
A typical example may be a BIF that behaves oddly, or crashes/core dumps, but may of course be other things.
In these cases it may be very hard to create a small program that shows the error, but if that's possible, that's of course appreciated...
If the error seems to be in the VM, also supply information about:
Sometimes the bug manifests as a hanging process or VM. If OTP needs a core file to analyze the problem, do like this:
os:getpid()to get the OS pid of the beam process
kill -ABRTto kill the process and dump a core. This only works if the
ulimitis set so that cores are dumped, otherwise use
gcoreto produce a core without killing the process (might hang it for a long time though, so be prepared for interrupted service)
Often when you have VM crashes, OTP will ask you for the complete core dump. For OTP to be able to read the core properly, the binaries usually need to be supplied as well (i.e. beam/beam.smp etc).
The best way to supply OTP with the relevant files is to pack the source tree where the OTP that crashed was built, if that is still available and not cleaned. This means the OTP distribution where you've run configure with the exact same parameters as you used when building the erlang VM that crashed and then have run 'make' to build all the binaries. Pack that in a compressed tar file together with the core and OTP will have a much better chance of finding the bug.
If there is an erl_crash.dump file, supply that as well.
The compressed tar file, which is probably quite large, can be delivered to OTP in many ways. Do however not put it on a public webserver without security and post the URL on the list. Core files may contain all sorts of sensitive information you do not want to spread (for security reasons).
You will probably have one single OTP developer to communicate with now, so send any information to her/him directly. Also, it may be a good idea to request a public gpg encryption key to use on any login information you would like to send to the developer.
The core and binaries can be fetched by OTP from either your FTP/Website, from your dropbox (in which case you could share it only to the developer at OTP) or by sending it through streamfile.
Go to Erlang/OTP at streamfile, then fill in the following data:
But only do this if someone at OTP has asked for the file, do never send corefiles or other large files if not requested to.
Also send an email to the developer informing her/him that you've submitted the file to streamfile.