It's quite literally a review of the code that has been written. Usually in Software Development projects the Lead or Principal Developer will want to conduct code reviews, usually using things like Version Control Pull Requests. The actual process of reviewing code is of course down to the whoever is the reviewer, maybe they are looking for something specific, or they have a general set of rules and standards that the code needs to live up to. If it's taking a long time then the process is probably not very good, or the chunks up for review are simply too large - I find that the best code review is on small additions / patches of recent work that is fresh in the memory of the reviewer (who is likely to have been part in the system architecture planning).
As for just accepting that the code runs on the developers machine, the reviewer may be looking at solution quality, e.g. just because it works does not mean that the solutions is good and optimal. Furthermore the reviewer may have experience regarding things that may or may not work on different systems and setups and therefore the fact that it works on the developers machine is not enough.
In short, the process of Code Review is an individual process that is important, but if it's taking so long that it significantly slows down development then the process may be flawed or the reviewer does not have the adequate experience to quickly spot whether or not an implementation is "good enough" to pass the review.
Code review also ensures that everyone is following the same in house standards with the code that they write. This will cover lots of things that do not make any difference to whether the code works or not such as indentation. It basically ensures that everyone's code is written the same way so that everyone can maintain all the code as if they were the sole programmer responsible for writing it.
On top of what has been mentioned code reviews are wonderful opportunity for you to learn from the senior developers -- there is a lot more than meeting the functional requirements to software development.
I'm currently in a dev team where Code Review is essential. Previous jobs, I did code review during meetings or other type of face-to-face meetings. Now, there are plenty of tools to perform code review where a developer can do it anytime. The cons is that un-reviewed code must be checked in. After that other developers can start looking at your changes. If it's to a point that it needs a re-write up then all you need to do is rollback the check-ins. I really do like code review since other catch my stupid mistakes but I don't get why we don't code review our techlead/architect codes..just seems a bit unfair.