Segmentation faults from perl when building ADL 4 source

[houchin]

Hi all,

Building ADL 4 has been a lot fussier for me than past versions, so I'm going back to try to document the issues I've found. On GRAVITE, I was able to use the standard perl that came with Linux. However, on a Scientific Linux 6.2 system at Aerospace, I'm getting segmentation faults from perl when I try to do the same:

Code: Select all

Building src in ./SCIENCE...
make[1]: Entering directory `/tcs/ago/group/viirs/adl/adl4/ADL/xml/SCIENCE'
/group/viirs/adl/adl4/ADL/perl/src/generateSourceFiles.pl /group/viirs/adl/adl4/ADL/xml/SCIENCE ADL -h /group/viirs/adl/adl4/ADL/include -o /group/viirs/adl/adl4/ADL/CMN/Utilities/Dictionary/Entries/SCIENCE/src -e AutoDerivedScienceDictionaryEntries -g AutoGeneratedScienceProductsGbl.h -d /group/viirs/adl/adl4/ADL/CMN/ProcessingIO/src -f AutoGeneratedScienceProductsGbl.f
make[1]: *** [/group/viirs/adl/adl4/ADL/include/AutoDerivedScienceDictionaryEntries.h] Segmentation fault (core dumped)
make[1]: *** Deleting file `/group/viirs/adl/adl4/ADL/include/AutoDerivedScienceDictionaryEntries.h'
make[1]: Leaving directory `/tcs/ago/group/viirs/adl/adl4/ADL/xml/SCIENCE'
make: *** [src] Error 2

I can understand a perl compile error, but I'm a bit surprised it's segfaulting perl. Any ideas? I really would rather not have to build my own perl, even though the UW script automates much of it.

Here's the perl version string for the bundled version: This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

[kbisanz]

Huh. Yeah it's strange to see a seg fault from perl.

My best guess is that maybe the modules you've downloaded for ADL aren't compatible with your perl version. That's a vague and unhelpful statement.

The version of perl we have is
v5.8.8 built for x86_64-linux-thread-multi

It says a core file was created. Is there any chance you could open that core with a debugger (gdb?) and get some sort of idea where it's having issues? Maybe you'll get lucky and it'll mention a module name to help narrow down the search.

[houchin]

Ok, I narrowed it down. The core file was unfortunately no help, but with some print statements I was able to generate a small code fragment that I could run independently:

Code: Select all

#!/usr/bin/perl

require XML::Simple;

my $parser = XML::Simple->new();

my $this = {};

$this->{Data} = undef;
$this->{XmlName} = undef;
$this->{IsValid} = 0;

bless($this, $class);

$xml = "/group/viirs/adl/adl4/ADL/xml/SCIENCE/EDR_TEMPLATE1_OUTPUT1_EDR.xml";
if (-f $xml)
{
	$this->{XmlName} = $xml;
	$this->{Data} = $parser->XMLin($xml,
		SuppressEmpty=>'',
		ForceArray=>['Field','Dimension','DictionaryMask','ProductData',
			         'Datum','Symbol','LegendEntry','FillValue']);
}

And the specific line in the UW derived envSetup file I'm using that triggers it:

Code: Select all

export LD_LIBRARY_PATH=${ADL_HOME}/lib:${COTS_LIB}/lib:${GCCLIB}/lib64

I will note that the ADL 3.1 version of this file did not set LD_LIBRARY_PATH, migrating to LD_RUN_PATH. I deleted this line from envSetup and ADL build and ran fine with the bundled Perl.

[kbisanz]

I'm glad to hear you got this working.

I guess perl was using LD_LIBRARY_PATH to find some libs and it was finding (and apparently trying to use) some incompatible ones due to the contents/order of LD_LIBRARY_PATH? Is that your understanding?

I'm a little curious when you say you deleted the line from envSetup. I believe LD_LIBRARY_PATH will need to get set someplace in ADL or else you won't be able to run any ADL executables (they need to find libs in ${ADL_HOME}/lib).

[houchin]

In my configuration, my pre-ADL LD_LIBRARY_PATH was actually blank. Linux no longer needs this variable to find things in the "standard" locations.

As an alternate, at least on Linux, you can now use LD_RUN_PATH at compile time to cause the linker to encode the search path in the binary. It's the equivalent of the -R linker flag. So once I've built ADL, the executables now know where to search for the libraries without worrying about the environment telling them.