Counting to infintiy problem
I'll describe what happens, and then describe why each router made the decisions that it made using the scenario from the question.

The starting situation is a steady-state where the routers $A$, $B$, and $C$ have the connectivity $$A\stackrel{1}{\to} B\stackrel{1}{\to} C$$
$B$ is connected to $C$ in one hop, $A$ is connected to $B$ in one hop, and $A$ knows that it is connected to $C$ via $B$ in two hops. 


The connection from $B$ to $C$ goes down. 
$B$ notices this and updates its distance information from $1$ to $\infty$.
Before $B$ notifies $A$ of the change, $A$ broadcasts an update saying that it has a route to $C$ in $2$ hops. 
$B$ updates its routing table to record its belief that it can reach $C$ in $3$ hops via $A$.
$B$ broadcasts an update saying that it has a route to $C$ in $3$ hops.
$A$ updates its routing table to record its belief that it can reach $C$ in $4$ hops via $B$.
Et cetera.


From the comments, your issue is with step $6$. If $A$ already has a route to $C$ in $3$ hops, why wouldn't it just ignore the worse route via $B$ in $4$ hops and stay at $3$ hops? Well, the purpose of a router is to route messages. If I give $A$ a message to send to $C$, it needs to know who to send it to so that it eventually reaches $C$. $A$ knows that it will need to send to the message to $B$ for it to most efficiently reach $C$. In particular, $A$ knows that its distance estimate for a route to $C$ is based on the distance estimate of $B$. So if $B$ says that the distance has increased, $A$ knows that the distance has also increased for it (unless it can find a better route).

Of course, this is exactly what we want. Given the following connectivity diagram, if the connection marked by $(*)$ goes down, we want $A$ to start routing via $D$ ($3$ hops) rather than $B$ ($4$ hops) to send messages to $F$. That $B$ had a $2$ hop path in the past shouldn't matter. If $B$ loses all connectivity to $F$ (e.g. the connection between $B$ and $C$ also goes down), we certainly don't want to keep trying to route through $B$ just because it was the best route in the past.
$$\require{AMScd}
\begin{CD}
A @&gt;&gt;&gt; @&gt;&gt;&gt; B @&gt;&gt;&gt; C \\
@VVV @. @V(*)VV @VVV \\
D @&gt;&gt;&gt; E @&gt;&gt;&gt; F @&lt;&lt;&lt; G
\end{CD}$$

To put it a different way, we're talking about a dynamic version of the Bellman-Ford algorithm where edges can be added or removed in an online manner. Removing edges, in particular, makes the updates no longer monotonic. That is, we can no longer only keep the "best" routes we've ever heard, and we instead have to deal with potential "retractions".

Returning the the original, simpler scenario, the issue is when $B$ receives an update from $A$ that $A$ has a $2$ hop route to $C$, $B$ doesn't know that this information is dependent on $B$'s route to $C$. If $A$ had said that its route to $C$ was via $B$, then $B$ would have realized that this route was no longer useful and would not have updated its routing table in step 4. The split horizon modification solves this particular scenario by simply not having $A$ inform $B$ about any routes that $A$ can only reach (directly) through $B$, so step 3 never occurs as far as $B$ is concerned.