Two errors wile compiling latest Tracktion with Juce 6.0.8

I’m updating my libraries right now, but I can’t get the latest Tracktion to work out of the box with the latest Juce (6.0.8).

The first problem is in the tracktion_engine::ExternalPlugin class, which has a juce::PluginDescription member, and calls PluginDescription::uniqueId and PluginDescription::depricatedUid quite often. But these members don’t seem to exist in the juce::PluginDescription class any more, and I can only see PluginDescription::uid.

The second problem is in choc_SampleBuffers.h, where I get an illegal indirection compiler error on line 473:

        auto allocated = new void*[1];
        *allocated = allocated;    // illegal indirection here (line 473)
        return { reinterpret_cast<SampleType* const*> (allocated), 0 };

I don’t really know what’s going on here, and the code looks pretty dodgy to me anyway.

I have slashed out line 473 in choc_SampleBuffers.h and edited the tracktion_engine::ExternalPlugin class so that it only refers to juce::PluginDescription::uid, and everything compiles fine again.

Based on this post, I’m assuming that Develop is the correct branch of Tracktion to be using, but I’ve tried it with Master and traction_graph as well, with the same result.

Thanks for your code-review :slight_smile:

It’s a bit arcane, sure, but it’s not a mistake, and commenting it out will mean that later when the memory is freed, it’ll be freeing a dangling pointer. If it hasn’t crashed for you it’s probably because you’ve been lucky enough that the memory happened to contain zero, and you’re just getting a leak instead of a crash.

I’m struggling to see any way that line could cause a problem - it allocates an array of pointers, and sets the first pointer in the array… very basic stuff and not much to go wrong there unless ‘new’ has returned a null pointer, which would be very odd (and probably indicative that something else had gone horribly wrong beforehand). My guess is that what you’re seeing is that some other code has corrupted the heap and this happens to be the next heap allocation to happen afterwards, or something like that.

1 Like

I’m getting compiler errors though, not runtime. I’m sure you’re right that commenting it out is a bad idea, but without doing so I can’t get it to compile.

Regarding the PluginDescription errors, it sounds like you need to update JUCE. These were changes made a couple of months ago and might only be on juce/develop. Generally, you should look at the juce commit tracktion_engine points at as that will be guaranteed to work as that’s what our CI builds and tests all the projects with.

Perhaps once that has been fixed the other error will go away?

That’s a very puzzling error message, it’s telling you that ‘allocated’ is not a pointer, but it definitely is one!

I know that the code builds and works fine in Visual Studio in many other contexts, so maybe like Dave suggested, if you can sort out the other errors, this one will magically disappear. Other than that, all I can think is that maybe in your project there’s an overridden ‘new’ operator somewhere which is returning a weird non-pointer type? (e.g. some kind of debugging utility or other tricks going on)

If you really can’t figure it out, something to try would be

void** allocated = new void*[1];

and see if that changes the error. If it does then you’ve definitely got something funky going on with your ‘new’ operator.

void** allocated = new void*[1] fixes it.

The strange thing is that I put the offending line of code auto allocated = new void*[1] elsewhere in my project and it compiles fine.

@dave96 Thanks, I’ll check out the develop branch.

A problem with auto type deduction? :thinking:

Well, I can only suppose that the compiler is treating the return type of new void*[1] as void* rather than void**. That’s a bit weird, but I suppose could be an edge-case in the C++ standard, so while it seems pretty dumb, I guess it might not be technically incorrect…

No idea what kind of config you must be using if this problem only happens to you and nobody else, but I will update it to explicitly say ’void** just to make sure!

1 Like

What specific compiler version are you using? It would be useful if we could replicate it.
If it really is just that type deduction it should be easy to replicate on godbolt.org

I’m using the MSVC compiler.

As I said, I tried replicating the same code outside of the choc file and it compiled fine. This suggests that perhaps it is something strange with the operator new function like jules was saying.

Can you just use something like that (lo-fi trick):

auto allocated = new void*[1];
typename decltype (allocated)::_;

To see the deduced type in that case?

For instance i get:

error: decltype evaluates to ‘void**’, which is not a class or enumeration type
  136 |         typename decltype (allocated)::_;

That’s a neat trick. I bet his shows up as a void*

Nice idea. I get a double pointer though!

'void **': left of '::' must be a class, struct or union (compiling source file ..\..\JuceLibraryCode\include_tracktion_engine_plugins.cpp)

I guess that rules out the operator new overload theory?

Very odd!

I guess that rules out the operator new overload theory?

No, it does the opposite: it rules out the “compiler is just always returning void* theory” which is what I was assuming.

Were you trying nicolasdenet’s trick in your original code base where you had the error, or just in a stand-alone test example?

FWIW I just had a quick go in Godbolt and I can’t find an MSVC version that gives the same error you saw. And that makes me think it must be something else in your codebase which is messing up the new operator…

FWIW I compile with Visual Studio 2019 V16.10.0 (treat warnings as errors, enabled), latest tracktion develop, and latest JUCE develop every day, and that error has never appeared.

Perhaps, doing a round of updating everything is needed?