xLightsSequencer / xLights

xLights is a sequencer for Lights. xLights has usb and E1.31 drivers. You can create sequences in this object oriented program. You can create playlists, schedule them, test your hardware, convert between different sequencers.
GNU General Public License v3.0
529 stars 196 forks source link

Fire Effect - per Preview crashes 2024.10 #4574

Closed brett-foy closed 2 months ago

brett-foy commented 2 months ago

xLights_dbgrpt-48176-20240520T162816.zip Describe the bug With 2024.10, on multiple sequences, I am experiencing frequent crashes. 9/10 times there is no debug package, but got one today. It would appear that the issue from my experience checking this file and previous logs is that there is an exception when rendering a fire effect w/ value curve on the height that is also a "per preview" render style. Not sure if the value curve on heights plays a role, but all of the effects I have seen render cause crash on have had this value curve.

To Reproduce Steps to reproduce the behavior: open sequence, render - crash happens in seconds

Expected behavior Rendering to work, no crash

Screenshots no screenshot, crash report attached

Versions (please complete the following information): Windows 11, w/ Nvidia GPU enabled (tried it with and without nvidia FFPMeg configured) xLights 2024.10

Additional context Add any other context about the problem here.

Attachments

Thanks!

cybercop23 commented 2 months ago

Can you create a new sequence and palce that effect with all the settings on one model and see if it crases. If, so, please upload that simple sequence.. don't really need the full/final sequence if you can reproduce with one effect on one model.

brett-foy commented 2 months ago

i love things that reproduce. see bug report attached, crashed when I added the third copy of the fire effect xLights_dbgrpt-29656-20240520T165840.zip

and it didnt include the sequence since it wasn't saved. hold on a sec

brett-foy commented 2 months ago

here it is with sequence saved. the crash happened right after I added the twinkle effect under the fire effect on the mega tree left front. so not sure if its a layers thing also.

easy fix is to not use per preview on the models, never happens if I do that.

image xLights_dbgrpt-39276-20240520T170327.zip

derwin12 commented 2 months ago

Easily duplicated .. perhaps related to https://github.com/xLightsSequencer/xLights/commit/51da6dc8d837c812e1663add3c20a82ddeee71d0

derwin12 commented 2 months ago

The y value goes beyond the size of the FireBuffer vector. int GetFireBuffer(int x, int y, std::vector<int>& FireBuffer, int maxWi, int maxHi)

maxWi=423, maxHi=726, size=305829 The FireBuffer is only 723*423=305829

brett-foy commented 2 months ago

I have noticed that the value curve seems to break at about 80% when the height curve gets to ~80% the effect just jumps to top of model. May be related?

Sent from my iPhone

On May 21, 2024, at 11:38 AM, Daryl @.***> wrote:



The y value goes beyond the size of the FireBuffer vector. int GetFireBuffer(int x, int y, std::vector& FireBuffer, int maxWi, int maxHi)

maxWi=423, maxHi=726, size=305829 The FireBuffer is only 723*423=305829

— Reply to this email directly, view it on GitHubhttps://github.com/xLightsSequencer/xLights/issues/4574#issuecomment-2123023020, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BEMWYBJRQ6OKTOEC3SHL2NTZDN2BBAVCNFSM6AAAAABIANJ6SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGAZDGMBSGA. You are receiving this because you authored the thread.Message ID: @.***>

derwin12 commented 2 months ago

@dkulp Dan something about this cached buffer .. it is not the right size. image

dkulp commented 2 months ago

This is definitely a wacky issue which points to some sort of thread safety issue. If you do something like:

Screenshot 2024-05-21 at 5 04 59 PM

you can see that two calls into GetMaxBuffer right after each other are resulting in different sizes. That's not good. Not even sure how to debug that. :(

cybercop23 commented 2 months ago

2 out of 3?

dkulp commented 2 months ago

GetMaxBuffer is also fairly expensive for "Per Preview" render styles. Thus, calling it every frame is not ideal anyway. I just pushed a change that only grabs the "max" during init and saves that for use with rendering the rest of the frames. This is faster as well as should provide consistency.

cybercop23 commented 2 months ago

@brett-foy you can grab that in the nightly and test it and will be avail in the next version.

brett-foy commented 2 months ago

testing looks good. also coincidentally fixed the value curve jump issue I mentioned above. thanks team!