Closed mattiasmaahl closed 2 years ago
I'll have a look either tonight or tomorrow. If you have the stack trace that will make the root cause obvious (I hope). If not, don't worry, as I'm sure I'll be able to reproduce on Linux. It's probably a relatively straightforward fix. (Famous last words.)
Sorry, No stacktrace available. 😞
the rows in the logfile above are the last rows in the logfile before the crash. all rows before those are from startup of the app.
No worries. Will have a proper look later. (Assert on Linux creates a core file which you open with gdb to get a stack trace, but I imagine it's a bit more complicated on Windows!)
Had a quick look. I think this is is because of lineEdit_hopUtilization->toSI()
in Equipment::save()
. It's not meaningful because the amount is a percentage, not a measure of a physical quantity, and therefore there is no SI unit for it - hence the assert. The fix is that, for this field, we should just use it without calling toSI()
. There may be one or two other fields with similar problems. Will check and do a patch tomorrow hopefully.
The short fix is in https://github.com/Brewtarget/brewtarget/pull/635. Will have a think about something that would flush these issues out at compile-time.
Correct me if I'm wrong, but don't you need values stored in the variables/objects for the functions to fail? values you don't have at compile time. A test could flush out such events though? just my 2 cents of thoughts?! 😄
It depends. In principle at least, we know at compile time whether a field holds a percentage, a date, a density, a duration, etc. Sometimes Qt makes it a bit harder because it doesn't play nicely with templates, but I think we can get the info from the subclass of BtLineEdit.
Ok, that's kinda cool! and your'e right of course, We know the Unit for the field ahead of time.
So I was creating a new Equipment.
To replicate:
Version, Brewtarget:develop (my own local build of the latest develop)
Brewtarget-log of the crash: brewtarget.log
Here's the code that Crashes:
src/UiAmountWithUnits.cpp:158~167
@matty0ung you have any idea what this could be?