Crash on OS X when optimizations are enabled -- memory allocation issue?

[Sidelobe]

I'm experiencing a weird crash on OS X 10.14.1 (Mojave) with any externals built with flext.

When I try to load a (flext-based) external, the app just closes / crashes.
I don't see any log entry in the system log nor the pd console (after I restart it).

What I did:

1. built and installed flex with build.sh (edited config file to match my installation, then build and install)
2. I build one of the tutorial externals (e.g. simple1 or signal1~) - by going into the tutorial/simple1 directory and then doing a ../../build.sh pd gcc
3. Install the built external
4. start puredata
5. create a new patch and (try to) add a new object

Is there another place where I could look for hints on why it crashes?

I'm using pd-0.49-1 and gcc -v yields:

Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin```

[Sidelobe]

I got it working!

The problem is, I don't know exactly why :-/

I suspect it was something in the build settings.
For future reference - here's my config-mac-pd-gcc.txt:

# (this should point to the main folder, which has a "src" (PD Vanilla) or "include" (PD extended) subfolder)
PDPATH=/Applications/Pd-0.49-1.app/Contents/Resources

# where is the PD executable?
PDBIN=$(PDPATH)/bin/pd

###############################################################

# prefix for flext installation
# headers are in $(FLEXTPREFIX)/include/flext
# libraries are in $(FLEXTPREFIX)/lib
# build system is in $(FLEXTPREFIX)/lib/flext

FLEXTPREFIX=/usr/local

###############################################################

# where should the external be built?
OUTPATH=pd-darwin

# where should the external be installed?
INSTPATH=$(PDPATH)/extra

###############################################################

# STK (synthesis tool kit) support
# http://ccrma.stanford.edu/software/stk

# where to find the STK header files (e.g. stk.h)
#STK_INC=/usr/local/include/stk

# where to find the STK library (normally libstk.a)
# (comment out STK_LIB if you don't use STK)
#STK_LIB=/usr/local/lib/libstk.a

###############################################################

# SndObj support
# http://music.nuim.ie//musictec/SndObj

# where to find the SndObj header files (e.g. sndobj.h)
#SNDOBJ_INC=/usr/local/include/sndobj

# where to find the SndObj library (normally libsndobj.a)
# (comment out SNDOBJ_LIB if you don't use SndObj)
#SNDOBJ_LIB=/usr/local/lib/libsndobj.a

###############################################################

# make flags (e.g. use multiprocessor)
MFLAGS=-j 2

# user defined compiler flags
UFLAGS += -ffast-math -mmacosx-version-min=10.12 -march=native

# user defined linker flags
LDFLAGS += -mmacosx-version-min=10.12 -framework Accelerate

# user defined optimization flags
OFLAGS += -O0 # -mtune=native

# user defined debugging flags
DFLAGS += -DFLEXT_DEBUG

# architecture-specific flags (optional)
UFLAGS_x86_64 +=
OFLAGS_x86_64 +=
DFLAGS_x86_64 +=

# cross-compilation (optional)
ARCH=x86_64

# SDK for 10.14
#OSXSDK=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

[grrrr]

Hi, thanks for your contribution. In fact, i don't see anything special in your configuration, other than maybe the "-O0" flag which says that no optimization takes place. There have been reports where "-O3" optimizations fail, with "-Os" being favorable instead. Please try it out, as DSP externals might suffer from missing optimization.

[Sidelobe]

OK, I've systematically tried LOTS of different settings and I have consisted behaviour: As soon as I enable optimizations (anything other than -O0), I get the crash.

I tried -O2, -Os and disabling -ffast-math and such... no combination works, except -O0

[grrrr]

Ok, closing this, since it is an effect of input/output buffer reuse as described in #37 .

[Sidelobe]

I disagree - this is completely unrelated to #37 ... this happens with the completely unmodified tutorial/signal1 program.

I still have no clue as to why this happens... it must be something in the build system?
Anyway, if no one else can reproduce, it might be a problem in my installation.

[grrrr]

Sorry, i misunderstood the problem - reopening the issue

[Sidelobe]

I've made a bit of progress -- I'm not 100% certain it's exactly the same issue though.

In the meantime, I've moved to Xcode to build a flext external... I'm not even using flext as a library, but building flext directly from source (makes things a lot easier for now).

As soon as I enable optimizations (any level), I get a EXC_I386_GPFLT (general protection fault).

The exception happens on the following line:

(line 89 in fifo.hpp)
      /* dummy pointer for head/tail */
      intrusive_fifo_node * dummy = new intrusive_fifo_node();

I do get several warnings of the type Replacement function 'operator new' cannot be declared 'inline', but I'm not convinced they are the root of the issue.

I'm ready to bet that this is the same issue happening when I build with the build system, only that now at least I have a hint on what could be the problem.

I've tried disabling FLEXT_USESIMD, but it doesn't seem to help...

Any idea what could be the problem?

[Sidelobe]

Great news!
I've managed to solve the crashes and am now able to build and use flext with optimizations enabled.

The issue was indeed hinted by the warning: Replacement function 'operator new' cannot be declared 'inline', which was triggered in flsupport.h, lines 129-135:

// define global new/delete operators
inline void *operator new(size_t bytes) NEWTHROW { return flext_root::operator new(bytes); }
inline void operator delete(void *blk) DELTHROW { flext_root::operator delete(blk); }
#ifndef __MRC__ // doesn't allow new[] overloading?!
inline void *operator new[](size_t bytes) NEWTHROW { return flext_root::operator new[](bytes); }
inline void operator delete[](void *blk) DELTHROW { flext_root::operator delete[](blk); }
#endif

Moving these definitions into flsupport.cpp (making them non-inlined) solved the problem for me!

Arguably, inlining the operators will not produce a huge performance improvement... so it would make sense to change this. Unless you've indeed detected serious performance losses on other platforms.

[grrrr]

Thank you for the contribution, would you care to submit a pull request for the changes?

[Sidelobe]

Gladly! Will do that today

[grrrr]

Solved by PR #38