I'm no expert on this, so this is probably not an optimal approach, but maybe it's worth a try...

Run "perl -d" to start a simple script that uses the suspect module(s). Then enter the "M" command to the debugger -- this will list all modules loaded so far, and their paths. (The list will include many that are loaded by "perl -d".

If you do M at the start of the debugging session, modules that are loaded via run-time "require" statements won't show up yet. So have an executable statement that follows whatever minimal module activity should trigger loading and applying the bad module(s), break on that statement, and issue "M" at that point.

If you can figure out a way to store the resulting list to a file, you can then easily follow up on the initial reply above: loop over the module files that are suspect and run "perl -cw" on each one. That's just a simple *n*x shell loop, or a simple perl script that runs a system() or backtick subprocess on each module file in the list.

But as others have pointed out, the stricture issue by itself may be of indeterminate (and inadequate) worth for finding the particular bug you're looking for. Still, knowing how many modules are involved, and all their path names, is bound to help in some way.

(Update: FWIW, using the debugger this way differs slightly from davido's excellent suggestion, in that it works without having to install the non-core Devel::Modlist module, in case that happens to be an issue for you.)