Smallest Common Multiple: So confused! 😢😢😢

Smallest Common Multiple: So confused! 😢😢😢


Tell us what’s happening:

I can’t understand whats wrong with my code. It gives correct answers till number “12” and goes haywire after that.

Your code so far

function smallestCommons(arr) {
  let answer = 1;
  let flag = 1;
  flag = 0;
    for (let j = arr[0]; j <= arr[1]; j++){
      if (answer % j !== 0){
        flag = 1;
  return answer;

console.log(smallestCommons([1,12])); //27720 : correct
console.log(smallestCommons([1,13])); //logs different numbers every time

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36.

Link to the challenge:


I do not understand why you set the initial value of answer to 1. I think it should start from the smallest bound of the range.

And I also needed to disable the infinite loop protection to be able to test the code, may be you need to take this into consideration and try your current code once more.

I used
here is the screenshot


Thank you @Tchoukoualeu . Yeah you are right, **answer **can start from the smallest bound of the range. However even this code worked well on (without caring for infinite loop protection)

But for some reason FCC editor isn’t allowing it.

Every time I refresh my console I get different answers for inputs 13 and above.
Any comments on this @randelldawson sir. Why this is happenning??


That means there might be something buggy about this challenge!?
may be!


Your code crashes my browser and locks my system, so without digging into it too much I can just say you’ve definitely created an infinite loop. I console logged j and for [1,13], j goes 2,3,4,5,6,7,8,9,10,11,12,13 over and over and over until the system runs out of memory, adding 1 to answer every time it goes past 13. Challenge is not bugged btw


No, @DanCouper the loop isn’t infinite, because I am getting correct result for input values < 13 on fcc editor. And on it works completely fine


I know the challenged is not bugged, and I know that there is some issue with my code (but its definitely not an infinite loop). I just can’t understand where I am going wrong and why the browser’s console and are showing different behaviours.


You do not have an infinite loop, but FCC’s test suite thinks you do, because your code takes longer than it expects. When this happens, the infinite loop protection feature kicks in and stops the “slow” code from continuing.

To resolve this issue, you must use a more efficient algorithm which is faster and does not cause the infinite loop protection to kick in. All of the FCC challenges can be solved with algorithms which are efficient enough to prevent the infinite loop protection from activating. Think how you could modify your current algorithm to achieve faster results.


The code is suppose to do that, till the answer= 360360. At this point it should come out of the loop and return the value of answer.


Yea I get that, but the infinite loop protection standard in-browser kicks in and it then breaks my system; I didn’t check if it was actually an infinite loop, just assumed so, so apologies for that. It’s just horribly inneficient, as @randelldawson says. It works in replit because replit evals whatever you put & executes that using Node, not the browser, whereas browsers have more stringent memory allowances