The odds are that you don't. Suppose that the problem was data corruption from a C library that it uses. Then the bug could quite literally be anywhere, and where it shows up is not very informative.

First of all, try to reproduce. Get all of the information that you can from logs, try to do it yourself. If you can, then try to do it in a controllable test environment. assuming that you can get it there, then try removing chunks of the program and reproducing it again. If a chunk seems to fix it, remove other chunks. You are trying to produce a test case, or else a good bug report. Doing this is a bit of an art, and a lot of luck. (The element of needed luck rises tremendously if the error is not deterministic. When something happens one time in 10,000, it is really hard to get feedback on whether you have made a difference or not with your latest edit...)

A second approach is to make a list of what modules it uses. Find out which ones load C libraries. For each one search for reports that it is associated with core dumps. (For instance I have seen reports that some database drivers will every so often.) This is kind of hit or miss, but sometimes you can identify a problem this way. An intimate familiarity with a wide variety of reported bugs may improve your odds slightly...

Speaking of which, a distinct possibility to look into is whether or not it is using a signal handler. Perl does not have safe signal handling, and in particular allocating memory within a signal handler can cause core dumps.

But unless you can find someone with an intimate familiarity with the internals of Perl, odds are that trying to debug a complex Perl script using gdb is going to be an uphill battle. (When I say "uphill", think Nepal...)