Segfault in psphot when used on chip images with -F flags

[welling]

Here's the command which produces the segfault- it's being run on odyssey.fas.harvard.edu with the top-of-tree SVN trunk code as of April 9. If the -F flags are omitted the segfault does not occur.

psphot
-file /n/data1/panstarrs/GPC1/MD01_20081002_1/36475/chip/o4741g0234o.36475.ch.11948.XY01.ch.fits -mask /n/data1/panstarrs/GPC1/MD01_20081002_1/36475/chip/o4741g0234o.36475.ch.11948.XY01.ch.mk.fits -variance /n/data1/panstarrs/GPC1/MD01_20081002_1/36475/chip/o4741g0234o.36475.ch.11948.XY01.ch.wt.fits -F PSPHOT.OUTPUT PSPHOT.OUT.CMF.MEF
-F PSPHOT.PSF.SAVEPSPHOT.PSF.SKY.SAVE
/n/data1/panstarrs/GPC1/MD01_20081002_1/workspace/jsw_pswarp/MD01_20081002_1/36475/chip/o4741g0234o.36475.ch.11948.XY01

The segfault is in psMetadataLookupStr; the full stack trace and a bit
of additional debug info is below. Note that the value of '*chip' is
0xdeadbeef . Looking up the stack, fpa is 0xdeadbeef in
pmFPAAddSourceFromView .

findChipType (chip=0xdeadbeef0bbf5000, contents=0xac53040) at
pmFPAConstruct.c:474
474 const char *chipName = psMetadataLookupStr(NULL, chip->concepts,
"CHIP.NAME"); Name of chip
(gdb) where
#0 findChipType (chip=0xdeadbeef0bbf5000, contents=0xac53040) at
pmFPAConstruct.c:474
#1 0x00002b1d883438f4 in addSource_CHIP_NONE (view=0xfa1b360,
fpa=0xfcf6f60, chip=0xdeadbeef0bbf5000,

format=0xac4f060, phdu=0xfa1b2b0, install=true) at

pmFPAConstruct.c:865
#2 0x00002b1d8834487d in addSource (fpa=0xfcf6f60, fpaObs=<value
optimized out>, phuView=0xf8c4af0,

header=0x0, format=0xac4f060, install=true) at pmFPAConstruct.c:1261

#3 0x00002b1d883456cc in pmFPAAddSourceFromView
(fpa=0xdeadbeef0bbf5000, fpaObs=0xac53040 "�0�\n",

phuView=0x2b1d88f29551, format=0x2b1d8903dee7) at

pmFPAConstruct.c:1401
#4 0x00002b1d88366d6c in pmFPAfileSuitableFPA (file=0xf661c30,
view=0x1036b240, config=0x97148e0,

pixels=false) at pmFPAfileFitsIO.c:85

#5 0x00002b1d883d50e0 in pmSource_CMF_WritePHU (view=0xac53040,
file=0xf661c30, config=0x2b1d88f29551)

at pmSourceIO.c:568

#6 0x00002b1d88364037 in pmFPAfileWritePHU (file=0xf661c30,
view=0x1036b240, config=0x97148e0)

at pmFPAfileIO.c:963

#7 0x00002b1d88365920 in pmFPAfileWrite (file=0xf661c30,
view=0xf86ee30, config=0x97148e0)

at pmFPAfileIO.c:406

#8 0x00002b1d883660ae in pmFPAfileIOChecks (config=0x97148e0,
view=0xf86ee30, place=PM_FPA_AFTER)

at pmFPAfileIO.c:78

#9 0x00000000004029c2 in psphotImageLoop (config=0x97148e0) at
psphotImageLoop.c:100
#10 0x0000000000401c52 in main (argc=<value optimized out>,
argv=0x7fff229d8268) at psphot.c:30
(gdb) p *chip
Cannot access memory at address 0xdeadbeef0bbf5000
(gdb) p *contents
$1 = {list = 0xac530f0, hash = 0xac533f0, lock = {data = {lock = 0,
count = 0, owner = 0,

nusers = 0, kind = 0, spins = 0, list = {prev = 0x0,

next = 0x0}},

size = '\0' <repeats 39 times>, align = 0}}

[welling]

Sorry; the input files are too large to attach.

[Paul Price]

This is due to specifying an inappropriate file rule (via the '-F' flags). pmFPAConstruct should be fixed to check for such user errors.