crashing in 4.1.6 and 4.1.7

[logandc99]

I sem to be getting crashing of lights to the point where I can't get much sequencing done. Not sure why this is happening so frequently.
I could use 4.1.7 because the program crashed every time I tried to save a sequence.
I rolled back to 4.1.6 which seemed ok at first but is now crashing every few minutes.
Any ideas?
I attached the latest bug report from Xlights

[nzlongfellow]

I've been doing several different sequences, new ones and adding to existing ones, tonight in 4.1.7 and saving without crashes unlike 4.1.6. Not much help to you, and I am not bragging, but just letting you know it does not happen to us all.

[logandc99]

Are you using windows or mac version?

Is anyone using the mac version of 4.1.7 without problems. Just trying to work out if it is mac specific or just my mac specific.

[scuba]

I'm getting crashes on my MAC also.  XL 4.1.7

[kevinp]

You're not alone.  I can't use 4.1.7 (Mac) at all with any previously saved sequence.  Just clicking on an effect (most of them) causes xLights to crash hard.  No debug report is generated.  I can, however, create a new sequence within 4.1.7 and use it normally and no crashes.  Seems to be affecting the Mac build only, as Gil has tested a couple of my sequences under Windows and all is fine for him.  Maybe Dan can look into this?  Might be hard without a debug report, and I'm not too sure how much the OS X crash report can tell him.

I see that a GitHub issue ticket was created 3 days ago for this on the Mac side.

[Gilrock]

The only change between 4.1.6 and 4.1.7 that I think could affect anything was Dan starting to store effect start and end times as integers representing a millisecond value instead of storing everything as doubles.  What I've seen is sometimes even though one effect might be placed directly to the right of another effect its start time ends up represented 1 millisecond earlier than the end time for the effect before it.  So I believe some of the crashing could possibly be related to that because the code doesn't work well if the effect durations overlap on the same layer.  I spent a couple hours last night trying to convert all the math for the effect positions over to using fixed point math instead of doubles but didn't finish the work yet.  I believe this will fix a lot of the issues I've seen happen with some of the crashing and some selection, copy, and paste issues that happen occasionally.  The positions will get rounded to the nearest boundary for the interval you've selected.  One of the hardest parts of making a change like this is now I've gotta deal with fixing up your old files when you open a sequence.  I'll need to convert all the times stored a double strings to an integer millisecond value.  Presets as well will need to be converted to the new storage scheme.

In the end this change will make the code perform even faster and use less memory.

[dkulp]

The main problem is I haven't been able to reproduce that crash at all with any of my old <=4.1.6 sequences.  If I cannot reproduce it, I cannot really fix it.    That's why it important to provide as much information as possible to help debug/reproduce it.   That includes providing all the xlights_* files from the show directory, the XML file for the sequence, and direct steps to reproduce (example:  open the file, expand the "Mega Tree" models nodes, click on the second effect, watch it crash).

[dkulp]

One more note:   I just grabbed the sequence/crash report from the first post and it seems to work fine with the 4.1.7b build  I just put up there.   I can load the sequence, render it, click on things, etc....   Not sure if it's something I fixed for 4.1.7b, but can you give that build a try and see if it helps?

[logandc99]

Well whatever you changed in 4.1.7b, it seems to have done the trick because I can save a sequence now 

The previous crashing on saving with 4.1.7 was a consistent thing for me no matter what mac I used and no  matter how many times i reinstalled the software. But 4.1.7b is not crashing on save on the macbook I just tried it on  .

Last night I seemed to be having new problems with 4.1.6 with the program crashing frequently, usually when I tried to change from one timing mark track to another. This happened 5 times on two different Macs. After I posted the problem, I then loaded a previous version of my sequence, saved the file immediately and was able to sequence for the next half hour without any problems. Weird. Must have been holding my tongue wrong or something.

Anyway, 4.1.7b seems to be the charm so.... thanks.

[kevinp]

The issue I was having with crashes has gone away with 4.1.7b.  I can now use sequences from previous versions.  Thank you Dan.

[nzlongfellow]

Are you using windows or mac version?

Is anyone using the mac version of 4.1.7 without problems. Just trying to work out if it is mac specific or just my mac specific.

Windows

[scuba]

All good here

[Gilrock]

Don't worry I probably have induced a bunch of new crashes for the next build.
I did massive sweeping changes to convert all effect positioning from doubles to fixed point millisecond ints.  Would be easy for some bugs to be lying around but once we fix everything it will be better off in the long run.  I also need to fix it so you can't move anything to any of the inbetween spots.  Like right now if you do an alt move like for a chase drag you can actually position effects in illegal spots.  Then when you save and reopen they all get moved to the quantized positions according to the sequence timing intervals.

[gerry]

Attached  is a crash report (4.1.17). Windows
Had been adding effects and saving for quite a while with no issues at all.
(seq is a mixture of LSP imported at the data level and then XL effects on several models)

Then , after a while, did a save - (no problem) , then whilst still in the sequence did a backup ie {File Backup} , no problem/error, then wondered if I had done a save , and to be sure did a save and it crashed.

Reopened and did a save again-  no problem/crash , so maybe doing a Backup with the seq open followed by a save is not correct ...
 

[Gilrock]

At this point we've checked in so many changes to the code since last release that unless the crash report shows something obvious we really need to wait and let you see how the next release performs.