It's actually not a good idea to calculate physics with variable steps (i.e. each physics calculation takes time to simulate as a paramater). This is bad for various steps: debugging hell, network simulation, demo record playback, etc.

Best thing is to use fixed time tick to simulate physics. So once a while you do simulation for your 50ms and then render world using interpolation between previous positions and newly calculated (or use some kind of predicting future object position). But render main (user controllable item) using positions recalculated for each frame from user input. This way world simulation will be less apprearing to be lagging.

And this way you'll solve your problem: if time passed from last render exceeds your simulation step (50ms) then just assume that exactly 50ms passed and calculate next state. it will not make your game playable if PC is not able to constantly simulate world in smaller time periods than real time, but user will get predictable behaviour (if these slowdowns are just happen from time to time) AND you get predictable behaviour while debugging your code using GUI debugger (pausing, stepping throught code etc.)