You're trying to debug b.pl and some module called by it, but you didn't give any information whatsoever about either (other than b.pl uses some module that's not on CPAN).

Well, let's see if the information you gave gives a hint. The value returned by system isn't negative, so it wasn't a problem launching the child.

$ perl -E'say 2304 & 255'
0
[download]

It didn't die from a signal, so someone called exit or die.

$ perl -E'say 2304>>8'
9
[download]

It exited from exit code 9. It's very unlikely that someone did exit(9), so it's likely from die or the internal equivalent. But if Perl died, it would have emitted an error message to STDERR. What error did you get?

As for what "9" means, Perl uses $! || $? || 255 as the value for the exit code when dieing. It's not always meaningful, but there's a chance it is.

$ perl -E'say $!=(2304>>8)'
Bad file descriptor
[download]

If you get the same result on your system, it's not meaningful. $! often ends up with that value when there are no errors.

gdluce:

I don't know the semantics of use very well (especially under CGI!), but if it acts like the normal unix PATH, then I'd guess that you have "." in your path and that display.pl is in the same directory that b.pl is in. Then when you're in the directory holding c.pl, when you execute it, display.pl can't be found. I'll leave it to you to research and/or verify.

More information might yield a better theory.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Update: added emphasized section.

'resides in the same directory' and system("../b.pl"); are likely the key bits of information. If display.pm is in the same directory as b.pl then when b.pl is executed in c.pl's context the current working will not be appropriate and the search for display.pm will fail.