Crash on windows with SPulsaxophone

[jcelerier]

Hello, on current master, on windows, given the attached source : FaustTester.zip

I get a segfault in the dsp->init(...); call.

I can't get any backtrace, I guess it's because it's llvm-generated code...

• It works correctly under Linux (not tested on mac)
• I'm building faust against LLVM 11
• Other DSPs work fine (I haven't tried them all but a majority works)

[jcelerier]

I did a quick pass over the example files, the following do crash upon call to init():

ambisonics/oneSourceToStereo.dsp
bela/FXChaine2.dsp
faustplayground/combined/FlappyFlute.dsp
faustplayground/combined/Flute.dsp
faustplayground/combined/Modulations.dsp
faustplayground/combined/Pulsaxophone.dsp
faustplayground/combined/RandomFlute.dsp
faustplayground/combined/TibetanBowl.dsp
faustplayground/combined/TibetanBowlMulti.dsp
faustplayground/effects/Flanger.dsp
faustplayground/effects/Modulations.dsp
faustplayground/effects/Phaser.dsp
faustplayground/generators/SFlute.dsp
faustplayground/generators/SModulation1.dsp
faustplayground/generators/SModulation2.dsp
faustplayground/generators/SModulation3.dsp
faustplayground/generators/SModulation4.dsp
faustplayground/generators/SPulsaxophone.dsp
faustplayground/generators/SRandomFlute.dsp
faustplayground/generators/STibetanBowl.dsp
phasing/flanger.dsp
phasing/phaserFlangerLab.dsp
physicalModeling/faust-stk/bass.dsp
physicalModeling/faust-stk/blowBottle.dsp
physicalModeling/faust-stk/bowed.dsp
physicalModeling/faust-stk/brass.dsp
physicalModeling/faust-stk/clarinet.dsp
physicalModeling/faust-stk/flute.dsp
physicalModeling/faust-stk/fluteStk.dsp
physicalModeling/faust-stk/glassHarmonica.dsp
physicalModeling/faust-stk/harpsi.dsp
physicalModeling/faust-stk/modalBar.dsp
physicalModeling/faust-stk/NLFeks.dsp
physicalModeling/faust-stk/NLFfm.dsp
physicalModeling/faust-stk/piano.dsp
physicalModeling/faust-stk/saxophony.dsp
physicalModeling/faust-stk/tibetanBowl.dsp
physicalModeling/faust-stk/tunedBar.dsp
physicalModeling/faust-stk/voiceForm.dsp
physicalModeling/mi-faust/10_PluckedString/pluckedString.dsp
SAM/effects/effectsForBrowser.dsp
SAM/flanger/flangerForBrowser.dsp

[jcelerier]

main.cpp:

int main(int argc, const char** argv)
{
  std::string err;
  err.resize(4097);

  const char* triple = "";
  int argc_ = 0;
  const char* argv_[1] = { nullptr };

  if(auto fac = createDSPFactoryFromFile(argv[1], argc_, argv_, triple, err, -1))
  {
    if(auto obj = fac->createDSPInstance())
      obj->init(44100);
  }
}

[sletz]

Which Faust version ? Are you using the binary distributed version? Or a libfaust version you compile yourself?

[jcelerier]

I'm building it myself, will try with the release

[sletz]

Which compiler?

[jcelerier]

LLVM 11 too

[sletz]

Do you mean clang 11 ?

[jcelerier]

yep sorry

[sletz]

First thing is to check if the published 2.30.5 has the same issue.

[jcelerier]

I can reproduce with 2.30.5 for voiceForm.dsp (tried in FaustLive)

[sletz]

voiceForm.dsp fails because it use ffunction. This should be detected yes (fixed in https://github.com/grame-cncm/faust/commit/0310039a06daa1b46f2242f9c6036cf094a3ce52), but in any case LLVM backend cannot execute it. But phasing/flanger.dsp correctly works in FL and so on...

[sletz]

Anything new on this?

[jcelerier]

oops not really sorry, but I'm doing a windows bug checking week, I should be able to get to it soon !

[jcelerier]

okay, I could try at commit cd87756bdb50b94d509d63ad2ee5efc5b80cc81b (tag: 2.30.5-rc1, tag: 2.30.5, origin/release-2.30.5) and it still crashes. I'm going to try updating LLVM to 12 instead

[jcelerier]

getting the same issue with LLVM 12 :(

I also tried various debug options from the faust commandline page: -d gives me a 500mb file -norm gives me a 50mb file -ct gives nothing -cat prints me some errors:

ERROR : RDTbl read index [-inf:inf] is outside of table range (65536) in SigRDTbl[SigTable[nil,65536,SigGen[sin[SigBinOp[2,9.58738e-05,SigFloatCast[SigBinOp[0,SigFixDelay[SigProj[0,SYMREC[W8]],0],-1]]]]]],SigIntCast[SigBinOp[2,65536,SigFixDelay[SigProj[0,SYMREC[W9]],0]]]]
ERROR : RDTbl read index [-inf:inf] is outside of table range (65536) in SigRDTbl[SigTable[nil,65536,SigGen[sin[SigBinOp[2,9.58738e-05,SigFloatCast[SigBinOp[0,SigFixDelay[SigProj[0,SYMREC[W8]],0],-1]]]]]],SigIntCast[SigBinOp[2,65536,SigFixDelay[SigProj[0,SYMREC[W13]],0]]]]

And then I moved to the "normal" options... and found out that adding -vec makes it not crash !

I also saw that message when trying -sch if that can be useful:

Call parameter type does not match function signature!
%struct.dspmydsp* %dsp
 i8*  call void @startAll(i8* %15, %struct.dspmydsp* %dsp) #3
in function allocatemydsp

and finally I tried to output it as llvm bitcode (with -o spulsaxophone.bc) and file tells me it is indeed llvm bitcode but llvm-dis & friends can't open it... I attached it spulsaxophone.zip

[tomoyanonymous]

Any updates on this?

Maybe related issues, the code which uses ef.transpose function causes crash on Windows.

import("stdfaust.lib");
s = hslider("pitchshift",0,-12,+12,0.1);
process = ef.transpose(1000, 1000, s)<:sp.panner(0.5);

I just tried with VST plugin compiled with an online compiler, tested on Max 8.1.8. It could be loaded but crashed after trying to load parameters & GUI by double clicking.

[jcelerier]

@sletz I improved my faust llvm tester and put it there with a CI and independent from the rest of ossia: https://github.com/ossia/faust-tester ; here are the current build failures I'm getting on windows. Some of them are false positives but there is a fair bunch of segfault: https://dev.azure.com/ossia/libossia/_build/results?buildId=2952&view=logs&j=fe1e1641-1be4-5360-0ce7-c421d6568073&t=0a0f2661-dcf7-5b62-0047-d12e25c1664d

In the above, faust is at commit 158eb575672167315d6c66ef8b4fd6ac5655e1dc and LLVM is 14 on all platforms

edit: this build is running the tests on all platforms: https://dev.azure.com/ossia/libossia/_build/results?buildId=2958&view=results

[jcelerier]

The amount of segfaults in the call to dsp->init() on windows makes me wonder if it's not maybe some code alignment issue or something like that ?

[sletz]

Could be... any more precise crash log?

[sletz]

Can you possibly test classInit, instanceConstants, instanceResetUserInterface, instanceClear separately before testing init ?

[jcelerier]

hmmm, I could not find classInit and I wonder if it's not at least part of the issue - I see it in llvm_dsp_aux.hh's llvm_dsp but it's not here in the public llvm-dsp.h, so maybe in some cases the vtables get warped ?

Otherwise I tried the following sequence of calls:

    obj->instanceInit(sr);
    obj->instanceConstants(sr);
    obj->instanceResetUserInterface();
    obj->instanceClear();
    obj->init(sr);

If I do so, it still crashes on obj->init(sr);.. currently debugging

[jcelerier]

My bad, I had removed a log message, it passes init in some cases and goes to compute.

For e.g. LPF it does the following once in fFactory->getFactory()->fCompute(fDSP, count, input, output);:

0x19d8a7f00a0                   56                            pushq %rsi
0x19d8a7f00a1  <+    1>         57                            pushq %rdi
0x19d8a7f00a2  <+    2>         55                            pushq %rbp
0x19d8a7f00a3  <+    3>         53                            pushq %rbx
0x19d8a7f00a4  <+    4>         48 83 ec 48                   subq $0x48, %rsp
0x19d8a7f00a8  <+    8>         c5 f8 29 74 24 30             vmovaps %xmm6, 0x30(%rsp)
0x19d8a7f00ae  <+   14>         89 d5                         movl %edx, %ebp
0x19d8a7f00b0  <+   16>         48 89 ce                      movq %rcx, %rsi
0x19d8a7f00b3  <+   19>         49 8b 38                      movq (%r8), %rdi
0x19d8a7f00b6  <+   22>         49 8b 19                      movq (%r9), %rbx
0x19d8a7f00b9  <+   25>         c5 fb 10 41 0c                vmovsd 0xc(%rcx), %xmm0 # xmm0 = mem[0],zero 
0x19d8a7f00be  <+   30>         c5 fb 10 71 14                vmovsd 0x14(%rcx), %xmm6 # xmm6 = mem[0],zero 
0x19d8a7f00c3  <+   35>         c5 f1 57 c9                   vxorpd %xmm1, %xmm1, %xmm1
0x19d8a7f00c7  <+   39>         c5 fb 5f c1                   vmaxsd %xmm1, %xmm0, %xmm0
0x19d8a7f00cb  <+   43>         c5 fb 59 41 04                vmulsd 0x4(%rcx), %xmm0, %xmm0
0x19d8a7f00d0  <+   48>         48 8d 54 24 28                leaq 0x28(%rsp), %rdx
0x19d8a7f00d5  <+   53>         4c 8d 44 24 20                leaq 0x20(%rsp), %r8
0x19d8a7f00da  <+   58>         48 b8 00 00 00 00 00 00 00 00 movabsq $0x0, %rax
0x19d8a7f00e4  <+   68>         ff d0                         callq *%rax

The crash occurs on the last displayed line, 0x19d8a7f00e4 <+ 68> ff d0 callq *%rax

I'm not an ASM expert by any margin but

0x19d8a7f00da  <+   58>         48 b8 00 00 00 00 00 00 00 00 movabsq $0x0, %rax
0x19d8a7f00e4  <+   68>         ff d0                         callq *%rax

looks suspiciously like

  auto func_ptr = 0x0;
  func_ptr();

[sletz]

I don't think we can ever debug ASM generated by LLVM. I need to understand more context here:

• how is LLVM compiled ? Microsoft compiler ? mingw ?
• how is libfaust compiled ?

[jcelerier]

I'm using this mingw-based clang 14: https://github.com/mstorsjo/llvm-mingw ; I build both the llvm development libs and faust with it

[jcelerier]

I managed to get a fairly small repro:

SR = fconstant(int fSamplingFreq, <math.h>);
process(x) = sin(SR) / cos(SR);

the sin / cos version also crashes. So this looks like maybe some math identity which could be recognized ? e.g. it optimizes that into a tan in the backend which for some reason would fail to call.. sin(SR) works for instance so I assume it can't be a call to sin or SR

edit: this code crashes in instanceConstants though

[jcelerier]

and got it - it looks like the default triple when passing "" is "x86_64-w64-windows-gnu" under mingw with clang ; apparently "x86_64-w64-windows-msvc" must be passed explicitly in that case (even if MSVC is not involved at any point of the chain in my case). phew...