Debug in VS2022

[DanH]

@Lindon thanks, I found the culprit and now have an open app in VS :thumbs_up:

[Lindon]

@DanH said in Debug in VS2022:

@Lindon thanks, I found the culprit and now have an open app in VS :thumbs_up:

yes - so now the fun begins....

[DanH]

@Lindon indeed! So when playing notes on my instrument the console spits out messages like the below - anything to worry about?!

The thread 0x206c has exited with code 0 (0x0).
The thread 0x20f4 has exited with code 0 (0x0).
The thread 0xbdc has exited with code 0 (0x0).
The thread 0x468 has exited with code 0 (0x0).

[DanH]

@Lindon @d-healey @Christoph-Hart

Ok I'm pretty sure the below is the bug I'm trying to locate. It happens very occasionally when switching presets via the usual browser (can be any preset). I have no idea what this is telling me so please let me know if you do! :)

The instrument contains a couple of samplers, Waveform Gens, Sine Wav Gen too....

### Loading user preset BA        2010

Assertion failed!

Program: D:\HALO-2\Binaries\Compiled\App\HALO-2 Debug.exe
File: C:\Users\Admin\Desktop\HISE-develop...\readerw...queue.h
Line: 566

Expression: !inSection && "ReaderWriterQueue does not support enqueuing or dequeuing elements from other elements' ctors and dtors"

[d.healey]

@DanH Why are you taking photos of your screen instead of screenshots?

[DanH]

@d-healey it's not my main machine and the internet is dodgy on there at the mo

[d.healey]

@DanH Ok, just checking your sanity, I thought the debugging might have got to you :D

[DanH]

@d-healey I suspect it will, given time!

Screenshot below!

[DanH]

@DanH so a quick google suggests this might have to do with the queuing and de-queuing of threads. What kind of threads should I have going on normally...?

[Christoph Hart]

That‘s just an assertion that is telling you that the UI notification queue is full (which might happen if the user preset restores multiple hundred controls). It‘s not an critical error though so if it keeps appearing, just remove that line and rebuild to silence the message.

[DanH]

@Christoph-Hart Ok thank you for looking! This is what came up with the crash and the call stack is the same as when the plugin crashes (in the error report).... Could this lead to the source of the crash?

[DanH]

@Christoph-Hart been running the project again and run into this twice now:

void PoolBase::DataProvider::Compressor::create(MemoryInputStream* mis, ValueTree* data) const
{
	ScopedPointer<MemoryInputStream> scopedInput = mis;
	
	static zstd::ZCompressor<SampleMapDictionaryProvider> dec;
	MemoryBlock mb;
	mis->readIntoMemoryBlock(mb);
	dec.expand(mb, *data);
	jassert(data->isValid());

[DanH]

@DanH in XCode I'm getting this:

	if (mc->getKillStateHandler().isAudioRunning())
	{
		if (mc->getJavascriptThreadPool().isCurrentlySleeping())
			return true;

		// The audio engine is not suspended. Wrap this call
		// into a killVoicesAndCall lambda.
		jassertfalse;

		return false;
	}

If anyone has any advice at all about errors or debugging please let me know!!

[d.healey]

@DanH Try stepping through the code (also going back through the call stack) to try to figure out the root of the issue. Does this actually cause a problem in a release build or is it just showing up in a debug build?

Try to recreate the issue in a minimal project.

[DanH]

@d-healey so the issue is crashing when switching presets. It could be any preset at any time. So rather than click through every preset (which I've done a lot of!) I made a timer which selects the next preset in the list every 2 seconds.

• it's least stable running the debug within XCode / VS2022. I get call stacks I haven't seen before here.

• The issue appears in release as well - hence the debugging.

• So the error could be in the call stack and not necessarily the final file it points at?

• In standalone builds the debug and release crash in the same thread (JUCE Message Thread Dispatch queue). The crash reports look different - I don't know how to reconcile this, in the sense that the numbers (e.g 0x10a2d7084) are different, but it's my assumption they are pointing at the same thing?

[d.healey]

@DanH Remove half of your presets and see if the problem is still there. If it is, remove half of the remaining presets and test again. Once you figure out which group of presets the problem one (or more than one) is keep repeating this process on that group until you find the culprit.

I suspect the problem isn't a specific preset though and something to do with the way your project handles one of the controls that the preset is restoring.

Yes the root cause of the issue isn't necessarily at the last point the call stack made it to. This is why you need to set break points and step through the code.

[DanH]

@d-healey Yes I don't think it's specific presets as it does seem random.

Ok how do I set break points?!

[d.healey]

@DanH

The same way you do in HISE ;)

Now is the time for you to go to YouTube and search for Debugging in Visual Studio.

[DanH]

@d-healey you mean set break points in the source code?

[d.healey]

@DanH I'm not sure what you mean. Break points are a feature of the IDE. You add them by clicking in the margin (I have a video on Patreon about HISE breakpoints).