I have a car that I made with 2 motors in the back and one motor in the front. The motors spin fine in the air but when I put it on the ground to test my program the motors stop. The robot itself isn't very heavy so I don't think that is the issue.
NXT and EV3 motors don't slip unless set to coasting. This means that any external means to speed up or slow down the motor will be counteracted by the motor control. I believe basically one or more of your motors is acting as a brake for the others because the controllers believe that they should act that way to obtain the desired speeds you programmed them. Even if all things are equal (desired motor speed, direction and wheel diameter), other minor variations within the motors can cause variations in the total speed that are counterproductive...
I once created a sumo bot having three motors, the intention being two motors for tank steering and an additional motor to provide extra power. I think this is similar as to what you are trying to achieve. My solution was to combine the motor speeds with differentials (as present in several technic vehicle sets)...
Can you post a picture of your car? Is it possible that the gearing is different, or wheel size is different, between the front & back? Maybe that would cause the gearing to bind up. Maybe try letting the front wheel free-spin (no motor) to see if the rear wheels will propel the car by themselves. If that works, switch it around, and let the rear wheels free-spin and see if the front motor can propel the car on its own. If so, note the speed of the car with the rear wheels motorized, and compare it to the speed of the car with the front wheel motorized. If it's different, then gear binding might be the issue.
Sounds/looks like a software issue. My first guess was that the program is jumping straight into a line following algorithm and that program is stopping as soon as it detects the table top. But, that would be fairly easy to test by approaching the table from the edge of the table, so the light sensor would stop the motors before the back wheels got close to the table.
Second guess. The line following algorithm starts up in a mode that runs the motors at a low power setting (less than 5), which works when suspended in air, but it not enough power to turn the wheels when on the table because there is some resistance (either the front wheels or ?). The line following is waiting for some rotation distance before moving to the next step and it waits forever.
Probably best to copy/paste sections of the program. Throw out half until something works.
Of course, a screenshot of the program would help.