search

grame-cncm / faust

Functional programming language for signal processing and sound synthesis
http://faust.grame.fr
Other
2.54k stars 319 forks source link

[LINUX] libfaust crash: corrupted size vs. prev_size on deleteDSPFactory / delete m_factory #221

Closed blackrain-audio closed 3 years ago

blackrain-audio commented 6 years ago

Ubuntu 14.04 i386 32 bits here.

DSP code compilation via createDSPFactoryFromString or File, createDSPInstance and dsp process seem to go fine.

deleteDSPFactory (or delete) triggers the crash: *** Error in faust/build/llvm-dev/embedding: corrupted size vs. prev_size: 0x08875fb8 ***

Tested on: g++ 5.5, g++7, clang 5 and 6 and llvm3.8, llvm5.0.2 and llvm 6.0

The following dsp code exposes the fault:

T = hslider("Period", 1.0, 0.1, 100.0, 0.01);
N = 44100.0/1000.0*T:int;
i = +(1)~%(N):-(1);
process = i,N*0.5 : < : *(2) : -(1);

Replacing the hslider line with a constant say T = 1.0; gets rid of the issue (calling delete does not crash the app).

Code without sliders appears to work fine, no crash on calling deleteDSPFactory; Strangly, the following bit of code does not crash on deleteDSPFactory:

level = hslider("Level", 0.25, 0.0, 1.0, 0.01);
process = *(level);

I can post a short app (mostly scraps form your help/docs on embedding faust) that I use to test the issue along with info on my build process if required.

Any pointers/help?

TIA

sletz commented 6 years ago

Yes please provide a test application + crash log if possible. Can you send the source file also?

blackrain-audio commented 6 years ago

The test app/tool:

// embedding.cpp
#include <limits.h>
#include <libgen.h>
#include <iostream>
#include <stdlib.h>

#include "faust/audio/dummy-audio.h"
#include "faust/gui/PrintUI.h"
#include "faust/dsp/llvm-dsp.h"

int main(int argc, char *argv[])
{
  // the Faust code to compile
#if 0
  std::string dspCode =
    "level = hslider(\"Level\", 0.25, 0.0, 1.0, 0.01);\n"
    "process = *(level);\n";
#endif

#if 1
  std::string dspCode =
    //  "T = 1.0;\n"
    "T = hslider(\"Period\", 1.0, 0.1, 100.0, 0.01);\n"
    "N = 44100.0/1000.0*T:int;\n"
    "a = 0.5;\n"
    "i = +(1)~%(N):-(1);\n"
    "process = i,N*a : < : *(2) : -(1);\n";
#endif

  // this code works fine too
  //std::string dspCode = "process = +(1)~_:-(1);";

  bool result = startMTDSPFactories();

  if (!result) {
    std::cout << "startMTDSPFactories() result: false" << std::endl;
  }

  std::string m_errorString;
  llvm_dsp_factory *m_factory = createDSPFactoryFromString("square", dspCode, 0, NULL, "", m_errorString, -1 );

  if (!m_factory) {
    std::cout << m_errorString << std::endl;
    return -1;
  }

  dsp *m_dsp = m_factory->createDSPInstance();

  PrintUI interface;
  m_dsp->buildUserInterface(&interface);

  m_dsp->init( 44100 );

  dummyaudio audio(BUFFER_TO_RENDER);
  audio.init("render", m_dsp);
  audio.start();

  // Render BUFFER_TO_RENDER buffers...
  audio.stop();

  // cleaning
  delete m_dsp;
  m_dsp = NULL;
  deleteDSPFactory( m_factory );
  m_factory = NULL;

  return 0;
}

Compile with:

 $ clang++-5.0 embedding.cpp ../lib/libfaust.a $(llvm-config-5.0 --cxxflags --ldflags --libs core) -lz -ldl -lcurses -lpthread -o embedding -ggdb -I../../architecture

libfaust built with:

$ cd faust/build
$ mkdir my_build
$ cd my_build
$ cmake -C ../backends/world.cmake -C ../targets/world.cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER=/usr/lib/llvm-5.0/bin/clang++ -DCMAKE_C_COMPILER=/usr/lib/llvm-5.0/bin/clang ..
$ make staticlib

# the test app/tool ...
$ cd ../llvm-dev
$ clang++-5.0 embedding.cpp ../lib/libfaust.a $(llvm-config-5.0 --cxxflags --ldflags --libs core) -lz -ldl -lcurses -lpthread -o embedding -ggdb -I../../architecture
$ ./embedding > out

crash:
*** Error in ./embedding: corrupted size vs. prev_size: 0x08c97920 ***
Aborted

No crash log but the message You see there, got a core dump though.

Just did a follow up on gdb and got to trace the crash to:

at faust/compiler/generator/llvm/llvm_dsp_aux.cpp:190

llvm_dsp_factory_aux::~llvm_dsp_factory_aux()
{
#ifndef LLVM_35
    delete fObjectCache;
#endif
    if (fJIT) {
        fJIT->runStaticConstructorsDestructors(true); // line 191
        // fModule is kept and deleted by fJIT
        delete fJIT; // <<<<<<<<<<<<<<<<<<<<  CRASHES HERE
    }
    delete fContext;
    delete fDecoder;
    stopLLVMLibrary();
}

*** Error in faust/build/llvm-dev/embedding: corrupted size vs. prev_size: 0x08875fb8 ***

Program received signal SIGABRT, Aborted.

Thanks for your fast reply.

sletz commented 6 years ago

Cannot reproduce the problem here on OS X + LLVM 6.0. Can you get with master-dev branch ? And possibly llvm-6.0 ? And possibly try to comment : fJIT->runStaticConstructorsDestructors(true); // line 191

blackrain-audio commented 6 years ago

Cannot reproduce the problem here on OS X + LLVM 6.0

Strange indeed. This is master-dev branch just pulled (905527b6d). I have tried llvm-6.0; Last night infact but deinstalled 6 to give 5.0.2 a try. I could reinstall 6.0 again if required but I know the results will be the same from last night experience (the whole last week tests infact).

sletz commented 6 years ago

And possibly try to comment : fJIT->runStaticConstructorsDestructors(true); // line 191

blackrain-audio commented 6 years ago

And possibly try co comment : fJIT->runStaticConstructorsDestructors(true); // line 191

Already tried that, the app crashes on which ever delete comes next.

sletz commented 6 years ago

I'm actually testing 64 bits here. Could it be a 32 bits issue? Any way to test a 64 bits build (LLVM + libfaust + your test code) on the same machine?

blackrain-audio commented 6 years ago

OK, so Installed LLVM 6.0.1 again, did a Fresh git repo clone, and ran the build on master-dev branch for both libfaust and the app.

Same results.

Also commenting out the lines you suggest on this setup gives the same results as well.

Sometimes I get the error from prev. posts, sometimes I get this one:

*** Error in ./embedding: free(): invalid next size (normal): 0x0968b028 ***
Aborted

And then, 1 or 2 out of 20 times I run the app, Everything works without a hinch (huh?).

It kind of sounds to me like a stray pointer / uninitialized chunk of code somewhere which affects only the 32 bits version (if that makes sense?) remember that all of LLVM versions I tried - 3.81, 5.01, 6.01, do the exact same thing.

Doing a few searches on the type of error, I get references to code that attemps to delete memory that has not been allocated, access/delete STL containers that are not owners of objects that they attempt to dealloc etc...

I'm actually testing 64 bits here. Could it be a 32 bits issue?

It certainly looks like so. No matter how much I hoped it wasn't because now it looks like I am on my own. Its been a while and there are no other reports of this issue yet. Really fewer 32 bits OS installs by the minute.

Any way to test a 64 bits build (LLVM + libfaust + your test code) on the same machine?

Only thing I can think of is a new OS install on a USB drive, but then that is pretty much as giving an Online 64 bit VM setup build a go. Will try the online VM setup first and report what I see.

Mean time, any one with success stories on linux i386 32 bits? Please let me know, thanks.

sletz commented 6 years ago

It actually crashes in LLVM itself right ? One more thing to text would be to rebuild and use LLVM in debug mode.

blackrain-audio commented 5 years ago

No. The program crashes in libfaust, right after several STL containers are deallocated in fact. I have not had the chance to investigate deeper to be able to tell how those containers are being used.

Mean time here is a buffer overflow I stumbled on lurking in compiler/documentator/doc.cpp:

faust/compiler/documentator/doc.cpp: In function ‘void prepareDocEqns(const std::vector<CTree*>&, std::vector<Lateq*>&)’:
faust/compiler/documentator/doc.cpp:505:13:

warning: ‘%03d’ directive writing between 3 and 10 bytes into a region of size 6 [-Wformat-overflow=]

 static void prepareDocEqns(const vector<Tree>& docBoxes, vector<Lateq*>& docCompiledEqnsVector)
             ^~~~~~~~~~~~~~

faust/compiler/documentator/doc.cpp:505:13: note: directive argument in the range [1, 2147483647]
In file included from /usr/include/stdio.h:937:0,
                 from faust/compiler/documentator/doc.cpp:41:
/usr/include/i386-linux-gnu/bits/stdio2.h:34:43: 
note: ‘__builtin___sprintf_chk’ output between 4 and 11 bytes into a destination of size 6
       __bos (__s), __fmt, __va_arg_pack ());

Add the space we are actually making use of...

--- a/compiler/documentator/doc.cpp
+++ b/compiler/documentator/doc.cpp
@@ -78,7 +78,7 @@
 #include "simplify.hh"
 #include "sourcereader.hh"

-#define MAXIDCHARS 5  ///< max numbers (characters) to represent ids (e.g. for 
+#define MAXIDCHARS 10  ///< max numbers (characters) to represent ids (e.g. for

 using namespace std;

Could you please patch it?

(oh and sadly this doesnt fix our crash - I got really excited when I found about it, patched and rushed to test only to fail again).

I tihink Our crash must be due to something similar to this one, or a double dealloc, a faulty STL dealloc etc, something like that.

TIA

sletz commented 5 years ago

define MAXIDCHARS 10 => OK, done on my local version

blackrain-audio commented 5 years ago

Awesome, Thanks.

Keep you posted of new findings...

blackrain-audio commented 5 years ago

I finally had a bit of time to do some tests today. The setup I used is identical to the one where all the first tests were done except this time this is a 64 bit system:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty

$ uname -a
Linux s8472-faust-dev 4.9.120 #1 SMP Wed Aug 15 22:48:26 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

The usual toolchain:

The results,

The build process is the exact same as described in my previous posts.

Now I am really puzzled.

Any Ideas? is there actually anyone out there on Linux with a successful story with libfaust?

TIA

sletz commented 5 years ago

You can possibly try to compile FaustLive here : https://github.com/grame-cncm/faustlive

Be sure to be on the "dev" branch.

blackrain-audio commented 5 years ago

You can possibly try to compile FaustLive here : https://github.com/grame-cncm/faustlive Be sure to be on the "dev" branch.

That was one of my early attempts.

Didn't fly either - Faust Live required different versions of quite some libs than the ones on my distro. Jumping to these would trigger a long list of dependecies for me. All I actually needed was to check FaustLib in action so next best thing was to take a look at the code but didn't find much new there.

Besides, it is FaustLib that is crashing on me be it 32 or 64 bit platform. It would crash the same for FaustLive.

Perhaps on a different distro. Is there anyone out there with sucess stories about FaustLive on linux?

sletz commented 5 years ago

I'll try on a Linux machine this week or next one.

sletz commented 5 years ago

We just added a new LLVM test here : https://github.com/grame-cncm/faust/tree/master-dev/tests/llvm-tests. Its work here on a Linux Manjaro with success. Can you test on your machine ?

blackrain-audio commented 5 years ago

I get the same results I've been getting from the beginning. Same crash. The app runs fine but crashes when deallocation takes place towards the end. So, is this an Ubuntu/Debian issue we are seeing here? Super weird. I will try with Manjaro and report back as soon as I can.

Thanks a lot for testing.

sletz commented 5 years ago

Since the code actually crashes when deallocating a LLVM data structure (delete fJIT;), It could be also interesting to test a pure LLVM example using the LLVM JIT (as in libfaust). Maybe the Kaleidoscope example that should be part of LLVM distribution: https://llvm.org/docs/tutorial/ ?

blackrain-audio commented 5 years ago

It could be also interesting to test a pure LLVM example using the LLVM JIT

The Kaleidoscope tutorial code compiles and works fine.

sletz commented 5 years ago

Hum... can you run the program with valgrind (http://valgrind.org)? Trying to detect a memory corruption issue?

blackrain-audio commented 5 years ago

Hum... can you run the program with valgrind (http://valgrind.org)? Trying to detect a memory corruption issue?

I actually need to go hands on to find out, really understand whats going on. Time's been very complicated on this end and there hasn't been a chance forme to dig in. Soon I hope.