Based on the insufficient evidence you've given, I would raise the following issues:

• Are you looking at the actual data file being used by the vendor in question, or is your diagnosis so far based on your own copy of that file?
• How did you detect the input data line at which the program hangs? Maybe the problem is in the data line after this one, or maybe there's some other factor that is causing the last line you "see" to be different from the line that actually caused the problem.
• When looking at that particular line (or any line in the data), how did you know that it "seems ok"? What if your script could not deal with some unexpected pattern of white-space characters? Are you looking at the file in such a way that you could spot that? (Certain control characters, especially "backspace" (0x08), can also cause problems that are hard to "see" if you don't look at the data the right way.)

Maybe a global sanity-check for the input data would be worthwhile -- e.g. a separate perl script that reads in the same set of input data and simply tests the assumptions made by your database-loader script -- to settle those issues.

Better yet, figure out what those tests should be, and include them in the database loader script itself, so it can reject bad data instead of choking on it. (But sometimes it can be easier to treat data validation as a separate, prior step.)

Apart from that, it's just as important (or more so) to spot the line in your code where the script is hanging. If you start it with the debugger, you can just let it run until it looks to be in its "hung" state, then hit ^C to interrupt it. That will tell you which line was executing when the interrupt was handled, and you can start poking around, looking at values of variables to figure out how things are different from what you would expect.