Crash upon hitting PLAY

[jamills6377]

OK - in debug format the build completed.

[jamills706]

OK - it crashed in the same spot in Monster Mash that it always does.
on line 1733 in std::vector<_Ty,_Alloc>
1732 #if _ITERATOR_DEBUG_LEVEL !=0
1733           _STL_VERIFY(_Pos < size(), "vector subscript out of range");
1734 #endif /* _ITERATOR_DEBUG_LEVEL !=0 */


at the end of 1733 is the red stop sign X with a message: "Unhandled exception at 0x00007FFAA6F897DC (ucrtbased.dll) in xLights.exe: An invalid parameter was passed to a function that considers invalid parameters fatal."


In the Call Stack window: >   Xlights.exe!std::vector<LORDataPair,std::allocator<LORDataPair> >::operator[](const unsigned __int64 _Pos) Line 1733   C++

[jamills6377]

FYI - the next line after what I posted above is the call to the SetManyChannels function.
So the crash occurred in setting up for that call, I would say.

[Gilrock]

Yeah you might need to backup a couple lines in the call stack.  Try to double-click each line until it opens up the LOREnhancedOutput.cpp file because inside the SetManyChannels function is where it probably started.  We might need to wait till I get home and could jump in a Zoom session and see it.

It looks like it crashed on a variable named lorBankData so if you get to that line where it crashed hover over the shift_offset and the "i" index variables and see what the values are.  One of them is outside the allocated size of the array.

This is good.  If we can cause a reliable crash in the debugger we can prevent it.

[jamills706]

only 2 line above it in the call stack and they are:
uccrtbased.dll!00007ffaa6f897dc()
ucrtbased.dll!00007ffaa6f89727()

But the line below is the call to:
Xlights.exe!OutputManager::SetManyChannels(long channel, unsigned char * data long size) line 211

on 211 is a for loop where i is 0 to < num_bankrecords

i is 9
in the next set of statements is an if statement - I wonder about it though - the comment above the if says that it is to send betweeen 0 and FF - but the if reads:
if(lorBankData[bank].value !0) && (lorBankData[bank].value !=0xFF)...

weel that is just saying its not 0 or not FF isn't really checking if it's between the two is it?

Anyway --- at that point i=9 and bank=0

in the call stack the next line is Line 953 in OutputManager::SetManyChannels ---and on that line variable sth get set to 1, then it goes on to:
stch = 1;
        left -= send;
        o = GetOutput(o->GetOutputNumber());

[jamills706]

forgot to say - num_BankRecords was = 10 so 9 was a valid number in that loop

[Gilrock]

It's that line 211 where it crashed.  Which doesn't make sense because if "bank" or "i" were out of range it should have crashed when iterating through the same array on line 201 using the same variables.  The comment is correct.  First I gather up all the channels that need to be set to 0 and build that part of the packet, second I gather all the channels being set to 0xFF, and third its processing all the channels that were not covered in the first 2 sections.

[jamills6377]

Ah - I just knew that wasn't checking to see if it was in-between 0 and 0xFF - that's why I asked.

Well then - at this point it's OK to wipe out what I have on screen now and run it again and see if I get the same results?

[Gilrock]

If you can hover over the bank variable on line 211 see what it's value is.  Also hover over lorBankData and see if it shows anything valuable.

Yes that line is actually making sure the value is between 0 and FF because if its not 0 and its not FF it has to be in-between.

[jamills6377]

Thought I mentioned those variables above but in case I didn't ...  i=9, bank =0 and nothing happens when i hover over the .value part...the actual lorBankData part shows: lorBankData {size=23}

[jamills6377]

Just out of curiosity - so that number that is not 0 and not 0xFF --- have you somewhere earlier verified that it is not out of that range - or do you create it and therefore know it must be between those if it not one or the other?

[Gilrock]

Ok yes I missed the line where you showed bank = 0.  Not easy to tell what's wrong because reviewing the code it should not be possible for either of those values to be out of range because they are set based on the sizes read directly from that array object.

[Gilrock]

Just out of curiosity - so that number that is not 0 and not 0xFF --- have you somewhere earlier verified that it is not out of that range - or do you create it and therefore know it must be between those if it not one or the other?

Its a wxByte so its only an 8 bit number.  It can't be greater than 0xFF and even if it was a larger integer that wouldn't cause that line to crash.

[jamills6377]

Ok - that makes sense.

So should I go ahead and rerun it again to see if it fails at the same point again?

[Gilrock]

Sure it won't hurt anything to try it again.  We might have to get on Zoom together so I can browse around and see if anything makes sense.