Hey guys!

I'm programming a pitch shifter audio unit plug-in. I use delays to get the pitch shifting effect. after a succesful building i try to validate the audio unit with auval but a get a Segmentation fault during the RENDER TESTS.

Since i'm just beginning to program and to develop plug-ins i really don't know what this error is all about. Here's the entire error report:

RENDER TESTS:
Input Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Output Format: AudioStreamBasicDescription:  2 ch,  44100 Hz, 'lpcm' (0x00000029) 32-bit little-endian float, deinterleaved
Render Test at 512 frames
/usr/bin/auval: line 11:   533 Segmentation fault      arch -i386 -ppc /usr/bin/auvaltool

i adapted code from a vst programming tutorial and tried to put it into the audio unit api.

so what's this error all about? where should i look in the code? where could be my mistakes? is this all information you need?

greetings and thanks in advance

patrick

A segmentation fault means that you write or read a memory block that doesn't belong to your plugin (e.g. outside a buffer's boundaries).

You can try to debug auval (auval is just a script, you need to use auvaltool as executable, though I remember some problems with getting auvaltool to validate an AU from XCode).

I experienced auval changing the processed block size without notifying the plugin (Juce-Plugin, didn't check further whether Juce didn't simply pass the notification), which could cause a segmentation fault if you copy the sample block to a buffer relying on an initialized block size.


Chris

Segmentation fault normally means a SIGSEGV was signalled by the system.

Basically, SIGSEGV gets signalled when your program causes a page-fault with an address that either points to an unallocated part of the process address space, or points to page for which you don't have the required access permissions (ie write on read-only page, jump to no-execute page, read from system-pages, etc..).

In practice it means an invalid memory access. Most common causes:

- dereferencing a null pointer; use a debugger and if the fault address is small (eg hex-value begins with 6 or 7 zeroes), then it's probably a null-pointer. Also sometimes you might get fault at 0xfffffffc or something similar if you try to call a virtual method on a null-pointer

- using uninitialized values: such values (whether pointers or numbers or whatever) will for all practical purposes contain random values (ie whatever was in that memory location already) and using such values will cause random things to happen, so always initialize every variable (ie set pointers to 0 if you have nothing else; unlike uninitialized values, you can then test for 0 to avoid the predictable null-pointer crash)

- reading/writing past array bounds: if you try to write beyond the actual array it will throw a SIGSEGV if the end of array happens to be exactly at page boundary and the next page isn't allocated; if the memory past the array is valid (in the "belongs to the process" sense), then such addresses will trash random memory which usually causes a SIGSEGV somewhere later (when the now-invalid values are used).

to debug your plugin in auval, add a "New Custom Executable..." with the path /usr/bin/auvaltool . for the arguments put something like -v aufx Ipef Acme (type man auval in terminal to see what the arguments mean) . Hopefully the debugger will show you where the error is.

thank you guys! that really helps me out, i try to check everything that might be wrong and let you know how i proceed!

alright i implemented auvaltool in xcode and build/run my code with it. i get two results, either it passes and doesn't stop at the RENDER TESTS, or it gives me this notification:

Program received signal: "EXC_BAD_ACCESS".
sharedlibrary apply-load-rules all
Warning: the current language does not match this frame.

This is the line

next = (rpi != dsize - 1 ? delay[rpi + 1] : delay[0]);

(gdb) continue
Program received signal: "EXC_BAD_ACCESS".

i'm programming in c++ ... i'm pretty new to all this, so i don't see what's wrong with that line. nevertheless is this really the reason, why it crashes sometimes? cause sometimes it even passes

moreover when it put my plug-in in logic and run audio through it i can't hear anything.. any suggestions?

Probably rpi+1 is outside the delay buffer. You can check the value of rpi with mouse over or in the debugger (cmd+shift+y in XCode 3.2).

Also it is safer to check for lower than instead of not equal:
next = (rpi < dsize - 1 ? delay[rpi + 1] : delay[0]);



Logic might decide to bypass your plugin after it raised an exception.


Chris

Welcome to the wonderful world of apple - they'll give you a tool that's supposed to be useful (auval) but won't give you the source to investigate what's going on.

Well, seems like with vst sdk it is possible to build an audiounit, so assuming that the vst audiounit wrapper is well tested (it should be), it should be possible to avoid the troubles that apple's approach causes altogether. The related sources are at {vst3.5 root}/public.sdk/source/vst/auwrapper. Not that I have tried, so I cannot make further comments about the possibility.

auwrapper.h contains the following comment:

The VST 3 SDK comes with an AudioUnit wrapper, which can wrap one VST 3 Audio Processor and Edit Controller as an AudioUnit effect/instrument.

This is true up to a certain point. VST3 SDK is still quite new and not used by lots of people so there are still some bugs/issues. But Steinberg is still working on it and continuing to improve it.

But VST3 is 6 years old!

.

I am not saying that it is not usable. this is just that there are some thing that needs to be tuned.
The problem is that as it has not been adopted by lots of developers, so it takes more time.

It reminds me the problems of COM in Windows. Interfaces are not supposed to be queried at runtime, they should be hardcoded and be visible at compile time, and be fully implemented if they are declared by an object. Doing otherwise delays the detection of problems from compilation time to the testing time. The later a problem is found, the more time it takes to fix. I'm sure they had a reason to use COM style interfaces, but seems like it has been a bit overused for the sake of consistency.