New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TimeLineWidget overflows #3284
Comments
Could be this bug in gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 |
I may have closed this prematurely. I'm trying to alter the optimization flags from |
@zonkmachine have you already tried |
I can reproduce this with any build type, not just Debug. The gcc bug you linked doesn't look related as it's about complex numbers. This particular overflow happens at src/gui/TimeLineWidget#L374: Engine::getSong()->setMilliSeconds(((((t.getTicks()))*60*1000/48)/Engine::getSong()->getTempo()));
// ^~~~~~~~~~~~~~~~~~~~~^
// product too big for 32bit int The same calculation |
Now I have, thanks!
It looks like the command really works but the bug persists. |
Let's peel that onion... Isn't it a bit more readable like this? Calculating left to right that will be an overflow at 2^31 / 60000 or right before 36000 ticks. Fits the bug description perfectly. (Divide ticks by 48 and then 140 BPM and end up at 5.3-ish minutes). Optimization will apparently (at least on the compiler I tried) combine those constants into 1250, and the calculation won't overflow until after some hours. But doing the same in the source doesn't help readability much, as of now one can figure out what's going on from the numbers. My suggestion for a quick fix: |
Yup, worked!
👍 |
This should work: |
| This should work: t.getTicks() * ( 60 * 1000 / 48 ) That should push the limit to some 4.5 hours at 140 BPM. Or half an hour at 999. I'd say good enough for all sane use cases. |
I must admit I'm a bit puzzled by this. I thought the literals were computed at compile time and would end up as 1250, with or without parentheses?
Yes please! Edit: OT comment removed. |
OK. I had a go and fixed that line, working on the RC3 release. I hope no one else was busy with this? Other potential problematic lines in Song.cpp #3284 (comment) |
tick_t x = t.getTicks();
x *= 60;
x *= 1000;
x /= 48; |
In my opinion something like this would be even more readable: Song * song = Engine::getSong();
song->setMilliSeconds( t.convertToMilliseconds( song->getTempo() ) ); That way all the "magic" numbers and the fact that you need to use the And some of the magic that's needed to instantiate the |
@michaelgregorius It sounds like you have a good plan there. I vote you assign this to yourself and go ahead with it. 🚜 |
@zonkmachine Done in #3701! |
I have just merged #3701 into master. |
Thanks! Sorry, I didn't review fast enough... |
With compile option
-DCMAKE_BUILD_TYPE=DEBUG
If you left-click and drag on the timeline you will eventually get negative numbers. On my machine this happens around ~5m19s at 140bpm. This is a bit early for the counter to overflow. It doesn't happen when playing, only if you click the timeline at a certain intervals. It looks like the computation is done by a too small integer when clicking the timeline.
To reproduce:
-DCMAKE_BUILD_TYPE=DEBUG
The text was updated successfully, but these errors were encountered: