mrray's picture

@mrray

Groups

  • Vuo Founder
mrray's picture

hi jaymie-

i think i may have narrowed it down a bit- it seems like an issue with how VuoCompiler is created (stack vs heap)?

this code crashes:

- (void) compileAndLoadComp:(NSString *)inPath  {
    [self _eject];

    pthread_mutex_lock(&runnerLock);

    loadDate = [[NSDate date] retain];

    string      inCompPath = string([inPath UTF8String]);
    string      filename = string([[[NSUUID UUID] UUIDString] UTF8String]);
    string      binPath = "/tmp/" + filename + ".bc";
    string      dylibPath = "/tmp/" + filename + ".dylib";
    cout << "dylibPath is " << dylibPath << endl;

    VuoCompiler     *tmpCompiler = new VuoCompiler(inCompPath);
    tmpCompiler->setCompositionPath(inCompPath);
    tmpCompiler->compileComposition(inCompPath, binPath, true, nullptr);
    tmpCompiler->linkCompositionToCreateDynamicLibrary(binPath, dylibPath, VuoCompiler::Optimization_FastBuild);
    delete tmpCompiler;

    runner = VuoRunner::newCurrentProcessRunnerFromDynamicLibrary(dylibPath, "/tmp", false);

    [self _startComp];

    pthread_mutex_unlock(&runnerLock);
}

this code does not crash:

- (void) compileAndLoadComp:(NSString *)inPath  {
    [self _eject];

    pthread_mutex_lock(&runnerLock);

    loadDate = [[NSDate date] retain];

    string      inCompPath = string([inPath UTF8String]);
    string      filename = string([[[NSUUID UUID] UUIDString] UTF8String]);
    string      binPath = "/tmp/" + filename + ".bc";
    string      dylibPath = "/tmp/" + filename + ".dylib";
    cout << "dylibPath is " << dylibPath << endl;

    VuoCompiler     tmpCompiler(inCompPath);
    tmpCompiler.setCompositionPath(inCompPath);
    tmpCompiler.compileComposition(inCompPath, binPath, true, nullptr);
    tmpCompiler.linkCompositionToCreateDynamicLibrary(binPath, dylibPath, VuoCompiler::Optimization_FastBuild);

    runner = VuoRunner::newCurrentProcessRunnerFromDynamicLibrary(dylibPath, "/tmp", false);

    [self _startComp];

    pthread_mutex_unlock(&runnerLock);
}
mrray's picture

not sure if the file was attached successfully, on review of the report i don't see it- if it got lost, here's a link to it: https://www.vidvox.net/download/VuoQuestions6.zip

mrray's picture

reproducible crash in VuoCompiler() with 2.0.0.10830

mrray's picture

Status: 

Vuo version: 

OS version: 

  • macOS 10.13

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

  • sample project included, build & run
  • alternate between clicking "Load 1st comp" and "Load 2nd comp" buttons until the app crashes.
  • crash is 100% reproducible on every machine we've tested so far.
  • crash almost always occurs within the first cycle or two (usually on 2nd click).
  • crash doesn't occur with the 2.0 alpha (2.0.0.10623)- only reproducible using the 2.0 public beta (2.0.0.10830).
  • stack usually looks something like this:

  • 0 0x00007fff58242b66 in __pthread_kill ()
  • #1 0x00000001053c10f0 in pthread_kill ()
  • #2 0x00007fff5819e1ae in abort ()
  • #3 0x00007fff582ade3d in nanozone_error ()
  • #4 0x00007fff582a1dde in _nano_malloc_check_clear ()
  • #5 0x00007fff582a1c23 in nano_malloc ()
  • #6 0x00007fff5829b241 in malloc_zone_malloc ()
  • #7 0x00007fff5829a5bf in malloc ()
  • #8 0x00007fff56099628 in operator new(unsigned long) ()
  • #9 0x00007fff5607ffc9 in std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >::__init(char const*, unsigned long, unsigned long) ()
  • #10 0x000000010040b969 in std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > std::__1::operator+<char, std::__1::char_traits, std::__1::allocator >(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, char const*) ()
  • #11 0x00000001003ab4cf in VuoCompiler::VuoCompiler(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) ()
  • #12 0x0000000100001877 in ::-[VuoHolder compileAndLoadComp:](NSString *) at /Users/testadmin/Documents/VuoQuestions6/VuoHolder.mm:50
  • #13 0x000000010000fb57 in ::__37-[AppDelegate loadSecondCompClicked:]_block_invoke() at /Users/testadmin/Documents/VuoQuestions6/VuoQuestions6/AppDelegate.mm:63

Have you found a workaround?: 

nope, sorry!

mrray's picture

VuoCompiler isn't compiling subcomps that have changed

mrray's picture

Status: 

Vuo version: 

Fixed in Vuo version: 

OS version: 

  • Mac OS 10.11

How severely does this bug affect you?: 

●●○○ — It's annoying but I can work around it.

Steps causing the bug to occur: 

i'm attaching a .zip which contains source code, a procedure, and all the attendant files for a reproducible test case. more generally:

  1. create a .vuo composition, save it to the node library
  2. create another composition that instantiates and uses the first comp you made as a subcomposition
  3. launch an application that uses a VuoCompiler to compile and link an executable. run the executable, and observe the output.
  4. modify the subcomposition in a manner that would be visible
  5. without quitting, compile/link the executable again. run the executable, and observe the output- i would expect the changes that were made to the subcomposition to be visible, but they are not: the compiled output reflects the state of the composition when it was compiled for the first time since the app was launched.

Have you found a workaround?: 

yes, relaunching the application- which suggests that other workarounds of this type (compiling the .vuo comps in another process) would also probably be effective.

Compositions: 

AttachmentSize
Package icon VuoQuestions6.zip38.67 KB