On Wed, Apr 30, 2014 at 9:38 AM, Dan Dennedy <dan@dennedy.org> wrote:
On Wed, Apr 30, 2014 at 6:05 AM, Juan Martin Runge <jmrunge@gmail.com> wrote:
Sorry for delay, but was busy with other problems.  I finally got the stack trace!  Melted was running for almost two days and almost without action (only one casual append or clean, but usta every 50 millis) and then I send circa 30 append commands one after the other. Here is the result:

I do not need the full log, but neither is the partial backtrace providing enough information. We will either need to increase the 10s to 100s in melted_local.c:sigsegv_handler(), or run melted in gdb and issue 'thread apply all bt' within gdb when it crashes. I will try to recreate the problem based on some MVCP usage patterns I see from your log above. I encourage you to do the same. In your system, Is the client that is calling USTA on a different thread/process & socket than the client calling CLEAN and APND?

I am able to reproduce a crash due to a race condition somewhere inside the avformat producer. It may be tricky to fix, but I am trying. There is probably some workaround you can do with MVCP, but I have not explored that. Perhaps stopping the unit before sending all these commands, or skipping the clean command and instead doing a wipe after appending, or putting a delay between append commands - my test sends as fast as possible, not even waiting for server to respond to each one.