Welcome to iraf.net Monday, May 20 2024 @ 06:35 AM GMT


 Forum Index > Archives > Sitemail Archives
 mkobjects on PC-IRAF
   
Anonymous: Guest
 10/17/2001 04:00PM (Read 1406 times)  



Hi there,I am having a bizarre problem running mkobjects under PC-IRAF 2.11.3, on a
700MHz PIII with 512MB RAM, running Redhat Linux 7.1.
I am trying to simulate a series of galaxy clusters at various redshifts,
so I am creating the object lists with gallist and then attempting to
create the images with mkobjects. However, after only a few runs I get
"segmentation violation" errors. Strangely enough, the same script running
on a Sun Solaris system gives no such errors. Is there a memory leak in
PC-IRAF, perhaps? Sometimes I get "PANIC in
`/iraf/iraf/noao/bin.redhat/x_artdata.e': segmentation violation" as an
additional error message.
I have tried rewriting my script to use less for... loops, but it still
crashes unfortunately.
Any ideas?Thanks in advance,Michael

 
Anonymous: Guest
 10/17/2001 04:00PM  



Hi Michael,
We haven't had any similar reports so this isn't a known problem.
A segfault usually indicates a coding error of some kind, perhaps a memory
leak. Would you be able to send us your script and parameter settings
for the tasks so we could try to reproduce it here?
In the meantime a liberal sprinking of 'flpr' commands in the
script may help by causing the task to be restarted more often. Anything
else you can think of to help reproduce the problem would also help (e.g.
only happens with FITS images and not .imh, etc).Regards,
Mike Fitzpatrick

 
Anonymous: Guest
 10/17/2001 04:00PM  



Hi Mike,Thanks for your reply! Yes, I had tried to put some "flpr"s in the script,
but unfortunately that didn't help. I also kept an eye on the memory load
by looking at the output from "top" while the script was running - didn't
see anything out of the ordinary.Well anyway, I'm enclosing the scripts in question. The first,
quickclust.cl, is the task that creates an artificial galaxy cluster from
the given parameters, using gallist and mkobjects. I make it a task using
"task quickclust = quickclust.cl".
The second, clusterfudge.cl, is just a wrapper script that runs quickclust
for a variety of redshifts, richnesses and morphologies. In both cases, I
have tried to add some meaningful comments to the code. And while I'm sure
my IRAF programming style isn't very elegant... like I said, it works on
Solaris 8 systems.
Any ideas?Look forward to hearing from you, and thanks in advance,Best RegardsMike
On Wed, 17 Oct 2001, Mike Fitzpatrick wrote:> Hi Michael,
> We haven't had any similar reports so this isn't a known problem.
> A segfault usually indicates a coding error of some kind, perhaps a memory
> leak. Would you be able to send us your script and parameter settings
> for the tasks so we could try to reproduce it here?
> In the meantime a liberal sprinking of 'flpr' commands in the
> script may help by causing the task to be restarted more often. Anything
> else you can think of to help reproduce the problem would also help (e.g.
> only happens with FITS images and not .imh, etc).
>
> Regards,
> Mike Fitzpatrick

 
Anonymous: Guest
 10/17/2001 04:00PM  



Hi Mike,
Thanks for the scripts, however, there are two Perl scripts needed
and perhaps another FITS file before I can actually run them here. Could
you send those along or perhaps put them in /pub on iraf.noao.edu for me?
I did run the MKEXAMPLES task to create a galaxy field (which calls
both GALLIST and MKOBJECTS) but after a few hours of continuous use there
was no crash. This may mean that some parameter or other you set in the
script is triggering the bug. Could the Perl scripts be creating invalid
input data (e.g. negative sizes, positions off the field, etc)?? Lastly,
could you repeat my tests to be sure that works on your machine also, all
I did was run the script int cnt
for (cnt=0; cnt < 500; cnt=cnt+1) {
mkexamples ("galfield", "junk")
imdelete ("junk")
}where the number of loop iterations is arbitrary. Please let me know if
this fails on your machine.Cheers,
-Mike

 
Anonymous: Guest
 10/17/2001 04:00PM  



Hi again Mike,OK, I just uploaded the two scripts to iraf.noao.edu, named dl and angsize
(IRAF doesn't seem to like the .pl) along with some necessary data files,
dl_*.dat. You might need to change the first line in the scripts to
according to where perl is installed in your system. Oh, and remember to
chmod +x them.
I also uploaded 0218-05_cut_1s_partx.fits, which is a 1024x1024 image I
have been creating the clusters on.I wonder if you can reproduce my error. FYI, this only seems to happen
once the redshift is beyond 0.5 - usually a few tens of iterations into
0.75, although that varies somewhat.By the way, thanks for your test script; I ran it 500 times and it didn't
crash. Which would suggest that the fault lies somewhere in my script,
like you said.Anyway, thanks again for your help,Best RegardsMike

 
Anonymous: Guest
 10/17/2001 04:00PM  



Hi Mike,
Thanks for the extra files. I'm able to reproduce it easily and
we're looking into it now and will get back to you once it found. I did
find that putting a 'flpr' after the 'quickclust' call in clusterfudge.cl
seemed to work around the problem.Cheers,
-Mike

 
Anonymous: Guest
 10/17/2001 04:00PM  



>From mhoenig@ast.cam.ac.uk Fri Oct 19 14:50:10 2001
From: Michael Hoenig <mhoenig@ast.cam.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
cc: <sites@tucana.tuc.noao.edu>, <valdes@tucana.tuc.noao.edu>
Subject: Re: mkobjects on PC-IRAFHi Mike,Thanks for the update - and it's interesting to see you can reproduce the
error so readily. Interestingly enough though in my case putting a "flpr"
after the "quickclust" call in clusterfudge.cl doesn't make any difference
as far as crashing goes.
Anyway, looking forward to hearing from you.Cheers,
Mike

 
Anonymous: Guest
 10/17/2001 04:00PM  



Hi Mike,Thanks for the update - and it's interesting to see you can reproduce the
error so readily. Interestingly enough though in my case putting a "flpr"
after the "quickclust" call in clusterfudge.cl doesn't make any difference
as far as crashing goes.
Anyway, looking forward to hearing from you.Cheers,Mike
On Fri, 19 Oct 2001, Mike Fitzpatrick wrote:> Hi Mike,
> Thanks for the extra files. I'm able to reproduce it easily and
> we're looking into it now and will get back to you once it found. I did
> find that putting a 'flpr' after the 'quickclust' call in clusterfudge.cl
> seemed to work around the problem.
>
> Cheers,
> -Mike

 
Anonymous: Guest
 10/17/2001 04:00PM  



>From valdes Tue Oct 23 14:56:36 2001
From: Frank Valdes <valdes>
To: mhoenig@ast.cam.ac.uk
Subject: Re: mkobjects on PC-IRAFHello Michael,I have been trying to track down the problem you have encountered
with ARTDATA. While we have a reproducible case, attempts to track it
down with debuggers or print statements alter the behavior so that the
error goes away. I suspect it is a problem with using an existing
output image rather than creating a new image.While we may spend some more time tracking this down I have some suggestions.
The simplest is use of "flpr". One thing which is subtle is that gallist
and mkobjects are part of the same executable process. I think there
may be some interaction between these. So you should put a flpr after
gallist and after mkobjects (put it right after the call and not around
calls to the higher level script). Another solution which I think will
work for you is to work with imh image format. You do "reset imtype=imh; flpr"
to change. After you produce your final simulation you can then convert
it back to fits with something like "imcopy abc.imh def.fits" and reset
imtype back.I hope this will help you accomplish your project.Yours,
Frank Valdes

 
Anonymous: Guest
 10/17/2001 04:00PM  



From: mhoenig@ast.cam.ac.uk (Michael Hoenig)
Subject: mkobjects on PC-IRAF
Date: 17 Oct 2001 09:00:21 -0700Hi there,I am having a bizarre problem running mkobjects under PC-IRAF 2.11.3, on a
700MHz PIII with 512MB RAM, running Redhat Linux 7.1.
I am trying to simulate a series of galaxy clusters at various redshifts,
so I am creating the object lists with gallist and then attempting to
create the images with mkobjects. However, after only a few runs I get
"segmentation violation" errors. Strangely enough, the same script running
on a Sun Solaris system gives no such errors. Is there a memory leak in
PC-IRAF, perhaps? Sometimes I get "PANIC in
`/iraf/iraf/noao/bin.redhat/x_artdata.e': segmentation violation" as an
additional error message.
I have tried rewriting my script to use less for... loops, but it still
crashes unfortunately.
Any ideas?Thanks in advance,Michael
>From valdes Thu Oct 18 08:48:08 2001
From: fitz@tucana.tuc.noao.edu (Mike Fitzpatrick)
Subject: Re: mkobjects on PC-IRAF
Date: 17 Oct 2001 16:59:34 -0700Hi Michael,
We haven't had any similar reports so this isn't a known problem.
A segfault usually indicates a coding error of some kind, perhaps a memory
leak. Would you be able to send us your script and parameter settings
for the tasks so we could try to reproduce it here?
In the meantime a liberal sprinking of 'flpr' commands in the
script may help by causing the task to be restarted more often. Anything
else you can think of to help reproduce the problem would also help (e.g.
only happens with FITS images and not .imh, etc).Regards,
Mike Fitzpatrick>From valdes Thu Oct 18 08:48:30 2001
From: mhoenig@ast.cam.ac.uk (Michael Hoenig)
Subject: Re: mkobjects on PC-IRAF
Date: 18 Oct 2001 07:33:45 -0700
Hi Mike,Thanks for your reply! Yes, I had tried to put some "flpr"s in the script,
but unfortunately that didn't help. I also kept an eye on the memory load
by looking at the output from "top" while the script was running - didn't
see anything out of the ordinary.Well anyway, I'm enclosing the scripts in question. The first,
quickclust.cl, is the task that creates an artificial galaxy cluster from
the given parameters, using gallist and mkobjects. I make it a task using
"task quickclust = quickclust.cl".
The second, clusterfudge.cl, is just a wrapper script that runs quickclust
for a variety of redshifts, richnesses and morphologies. In both cases, I
have tried to add some meaningful comments to the code. And while I'm sure
my IRAF programming style isn't very elegant... like I said, it works on
Solaris 8 systems.
Any ideas?Look forward to hearing from you, and thanks in advance,Best RegardsMike[quickclust.cl included here. See vmware:itest1]
[clusterfudge.cl included here. See vmware:itest1]From: fitz@tucana.tuc.noao.edu (Mike Fitzpatrick)
Subject: Re: mkobjects on PC-IRAF
Date: 18 Oct 2001 16:37:45 -0700
Organization: IRAF Project, National Optical Astronomy ObservatoriesHi Mike,
Thanks for the scripts, however, there are two Perl scripts needed
and perhaps another FITS file before I can actually run them here. Could
you send those along or perhaps put them in /pub on iraf.noao.edu for me?
I did run the MKEXAMPLES task to create a galaxy field (which calls
both GALLIST and MKOBJECTS) but after a few hours of continuous use there
was no crash. This may mean that some parameter or other you set in the
script is triggering the bug. Could the Perl scripts be creating invalid
input data (e.g. negative sizes, positions off the field, etc)?? Lastly,
could you repeat my tests to be sure that works on your machine also, all
I did was run the script int cnt
for (cnt=0; cnt < 500; cnt=cnt+1) {
mkexamples ("galfield", "junk")
imdelete ("junk")
}where the number of loop iterations is arbitrary. Please let me know if
this fails on your machine.Cheers,
-Mike>From fitz Fri Oct 19 12:19:11 2001
Date: Fri, 19 Oct 2001 12:19:10 -0700 (MST)
From: Mike Fitzpatrick <fitz>
To: valdes
Subject: RedHat MKOBJECTS segvio
I've set up the test case on 'vmware' in the itest1 login directory
(use 'iRaf-twg1'). Just log into the CL an execute cl> cl < clusterfudge.clThe task should fall over on about the 8th image in the mkt_profile()
routine in a mfree() of the 'prof' pointer. When I tested this last night
using a memory debugger it went away so it's not as simple as an array
overrun. Let me know if you need anything else, original report is in
sitemail.Thanks,
-Mike>From fitz Fri Oct 19 12:23:13 2001
Date: Fri, 19 Oct 2001 12:23:11 -0700 (MST)
From: Mike Fitzpatrick <fitz>
To: mhoenig@ast.cam.ac.uk
Subject: Re: mkobjects on PC-IRAF
Cc: sites, valdesHi Mike,
Thanks for the extra files. I'm able to reproduce it easily and
we're looking into it now and will get back to you once it found. I did
find that putting a 'flpr' after the 'quickclust' call in clusterfudge.cl
seemed to work around the problem.Cheers,
-Mike>From mhoenig@ast.cam.ac.uk Fri Oct 19 14:57:40 2001
Date: Fri, 19 Oct 2001 22:50:05 +0100 (BST)
From: Michael Hoenig <mhoenig@ast.cam.ac.uk>
To: Mike Fitzpatrick <fitz@noao.edu>
cc: <sites@tucana.tuc.noao.edu>, <valdes@tucana.tuc.noao.edu>
Subject: Re: mkobjects on PC-IRAFHi Mike,Thanks for the update - and it's interesting to see you can reproduce the
error so readily. Interestingly enough though in my case putting a "flpr"
after the "quickclust" call in clusterfudge.cl doesn't make any difference
as far as crashing goes.
Anyway, looking forward to hearing from you.Cheers,Mike>From valdes Mon Oct 22 08:04:51 2001
From: fitz@tucana.tuc.noao.edu (Mike Fitzpatrick)
Subject: Re: mkobjects on PC-IRAF
Date: 19 Oct 2001 12:23:14 -0700Hi Mike,
Thanks for the extra files. I'm able to reproduce it easily and
we're looking into it now and will get back to you once it found. I did
find that putting a 'flpr' after the 'quickclust' call in clusterfudge.cl
seemed to work around the problem.Cheers,
-Mike
>From valdes Tue Oct 23 14:56:36 2001
Date: Tue, 23 Oct 2001 14:56:35 -0700 (MST)
From: Frank Valdes <valdes>
To: mhoenig@ast.cam.ac.uk
Subject: Re: mkobjects on PC-IRAF
Cc: fitzHello Michael,I have been trying to track down the problem you have encountered
with ARTDATA. While we have a reproducible case, attempts to track it
down with debuggers or print statements alter the behavior so that the
error goes away. I suspect it is a problem with using an existing
output image rather than creating a new image.While we may spend some more time tracking this down I have some suggestions.
The simplest is use of "flpr". One thing which is subtle is that gallist
and mkobjects are part of the same executable process. I think there
may be some interaction between these. So you should put a flpr after
gallist and after mkobjects (put it right after the call and not around
calls to the higher level script). Another solution which I think will
work for you is to work with imh image format. You do "reset imtype=imh; flpr"
to change. After you produce your final simulation you can then convert
it back to fits with something like "imcopy abc.imh def.fits" and reset
imtype back.I hope this will help you accomplish your project.Yours,
Frank Valdes>From mhoenig@ast.cam.ac.uk Tue Oct 23 18:40:43 2001
Date: Wed, 24 Oct 2001 02:40:37 +0100 (BST)
From: Michael Hoenig <mhoenig@ast.cam.ac.uk>
To: Frank Valdes <valdes@noao.edu>
cc: <fitz@tucana.tuc.noao.edu>
Subject: Re: mkobjects on PC-IRAF
Dear Frank (and Mike),Thanks for all your help. I followed your suggestion of putting a "flpr"
immediately after my gallist and mkobjects calls. Unfortunately, this
didn't stop the crashing.However, for scientific reasons I recently changed my quickclust.cl task
slightly - attached, along with an updated clusterfudge.cl. The only
difference is in the way I set minmag and maxmag: I now do it indirectly
via a third parameter. When I run this version under Linux, it doesn't
crash! I've tried it twice now and re-ran the old version which still
crashed somewhere around z=0.5.
Interesting, isn't it. Seems like such an insignificant change. Are you
able to say why this is making a difference?Thanks again for your help.Best Regards,Mike
==== quickclust.cl ====
# simulates a galaxy cluster, in a quick and dirty kind of way...
#
# task quickclust=quickclust.clprocedure quickclustint ngals {100, prompt="No. of galaxies in cluster"}
real z {0.5, prompt="Redshift"}
real r_core {0.1, prompt="Core radius in h^-1 Mpc"}
real r_max {1.0, prompt="Cutoff radius in h^-1 Mpc"}
real alpha {-0.9, prompt="Schechter LF alpha"}
real mstar {17.5, prompt="Schechter LF M^star"}
string mag {"m", prompt="M (absolute) or m (apparent) magnitude?", enum="M|m"}
real k {0., prompt="K-correction"}
real a {0., prompt="Extinction"}
real magw {6., prompt="Magnitude range"}
real egalmix {1., prompt="Proportion of elliptical galaxies"}
real r_h {3., prompt="Half-light radius in h^-1 kpc"}
real xcent {INDEF, prompt="X coordinate of centre"}
real ycent {INDEF, prompt="Y coordinate of centre"}
real O_M {0.3, prompt="Omega_M"}
real O_L {0.7, prompt="Omega_Lambda"}
real H_0 {70., prompt="H_0\n"}
string img {"0218-05_cut_1s_partx.fits", prompt="Image to use"}
real exptime {1., prompt="Exposure time"}
real magzero {20.8, prompt="Magnitude zeropoint"}
real gain {12., prompt="Gain\n"}beginint l_ngals
real l_z, l_r_core, l_r_max, l_alpha, l_mstar, l_egalmix, l_r_h
real l_minmag, l_maxmag, l_exptime, l_magzero, l_gain, l_xcent, l_ycent
real l_k, l_a
real Om, Ol, H0, h1, scale
real gcore, gmax, grh
string l_img, inlist, outimg, l_mag
int xdim, ydim
real xc, yc, xmin, xmax, ymin, ymax, d_l, m_star, l_magwl_ngals = ngals
l_z = z
l_r_core = r_core
l_r_max = r_max
l_alpha = alpha
l_mstar = mstar
l_egalmix = egalmix
l_r_h = r_h
#l_minmag = minmag
#l_maxmag = maxmag
l_img = img
l_exptime = exptime
l_magzero = magzero
l_gain = gain
l_xcent = xcent
l_ycent = ycent
l_k = k
l_a = a
l_mag = mag
l_magw = magwOm = O_M
Ol = O_L
H0 = H_0
h1 = 100. / H0
scale = 0.457# print ("Creating list of galaxies")

task $angsize = "$foreign"
angsize (Om, Ol, H0, l_z, l_r_core*h1) | scan (s1)
gcore = real(s1) / scale
angsize (Om, Ol, H0, l_z, l_r_max*h1) | scan (s2)
gmax = real(s2) / scale
angsize (Om, Ol, H0, l_z, l_r_h*h1/1000.) | scan (s3)
grh = real(s3) / scaleif (l_mag=="M")
{
task $dl = "$foreign"
dl (Om, Ol, H0, l_z) | scan (s1)
d_l = real(s1)
m_star = l_mstar + 25. + 5. * log10(d_l) + l_k + l_a
}
else if (l_mag=="m") m_star = l_mstarl_minmag = m_star - l_magw / 2.
l_maxmag = m_star + l_magw / 2. hedit (images=l_img, fields="i_naxis[1]", value=".", add=no, delete=no, verify=no, show=yes, update=no) | scan (s1, s2, s3)
xdim = int(s3)
hedit (images=l_img, fields="i_naxis[2]", value=".", add=no, delete=no, verify=no, show=yes, update=no) | scan (s1, s2, s3)
ydim = int(s3)
if (l_xcent == INDEF) xc = xdim / 2.
else xc = l_xcent
if (l_ycent == INDEF) yc = ydim / 2.
else yc = l_ycent
xmin = xc - gmax
if (xmin < 1) xmin = 1.
xmax = xc + gmax
if (xmax > xdim) xmax = xdim
ymin = yc - gmax
if (ymin < 1) ymin = 1.
ymax = yc + gmax
if (ymax > ydim) ymax = ydiminlist = "cluster.in"
if (access(inlist)) delete (inlist, ver-, >& "dev$null")gallist.gallist = inlist
gallist.ngals = l_ngals
gallist.interactive = nogallist.spatial = "hubble"
gallist.xmin = xmin
gallist.xmax = xmax
gallist.ymin = ymin
gallist.ymax = ymax
gallist.xcenter = xc
gallist.ycenter = yc
gallist.core_radius = gcore
gallist.base = 0.
gallist.sseed = INDEFgallist.luminosity = "schecter"
gallist.minmag = l_minmag
gallist.maxmag = l_maxmag
gallist.mzero = 0.
gallist.alpha = l_alpha
gallist.mstar = m_star
gallist.lseed = INDEFgallist.egalmix = l_egalmix
gallist.ar = 0.3
gallist.eradius = grh
gallist.sradius = 1.
gallist.absorption = 0.
gallist.z = l_zgallist.nssample = 100
gallist.sorder = 10
gallist.nlsample = 100
gallist.lorder = 10gallist.rbinsize = 10.
gallist.mbinsize = 0.5
gallist.dbinsize = 0.5
gallist.ebinsize = 0.1
gallist.pbinsize = 20.gallist (gallist=inlist, ngals=l_ngals)# print ("Performing mkobjects")outimg = "cluster.fits"
if (access(outimg)) delete (outimg, ver-, >& "dev$null")mkobjects.input = l_img
mkobjects.output = outimgmkobjects.objects = inlist
mkobjects.xoffset = 0.
mkobjects.yoffset = 0.
mkobjects.star = "moffat"
mkobjects.radius = 1.
mkobjects.beta = 2.5
mkobjects.ar = 1.
mkobjects.pa = 0.
mkobjects.distance = 1.
mkobjects.exptime = l_exptime
mkobjects.magzero = l_magzeromkobjects.gain = l_gain
mkobjects.rdnoise = 0.
mkobjects.poisson = no
mkobjects.seed = INDEFmkobjects.comments = yesmkobjects (input=l_img)end==== clusterfudge.cl ====
real z, z1, z2, zstep
int n, n1, n2, nstep
int i, imax
real kstar, kcorr, hstar, emix
string outstr, zs, ns, es, is, clist, climgz1 = 0.25
z2 = 1.50
zstep = 0.25n1 = 10
n2 = 100
nstep = 10imax = 10
clist = "cluster.in"
climg = "cluster.fits"quickclust.r_core=0.1
quickclust.r_max=1.
quickclust.alpha=-0.9
quickclust.mag="m"
quickclust.k=0.
quickclust.a=0.
quickclust.magw=6.
quickclust.r_h=3.
#quickclust.minmag=13.
#quickclust.maxmag=22.
quickclust.xcent=INDEF
quickclust.ycent=INDEF
quickclust.O_M=0.3
quickclust.O_L=0.7
quickclust.H_0=70.
quickclust.img="0218-05_cut_1s_partx.fits"
#quickclust.img="0218-05_cut_1s_sky_2k.fits"
quickclust.exptime=1.
quickclust.magzero=20.8
quickclust.gain=12.for (z=z1; z<=z2; z=z+zstep)
{
printf ("%.2f\n", z) | scan (zs)
quickclust.z=z
kstar = 6. * z**0.6 * exp(-0.15*z) + 13. # fudge alert Smile for (n=n1; n<=n2; n=n+nstep)
{
printf ("%03.0f\n", n) | scan (ns)
quickclust.ngals=n

for (emix=0.; emix<=1.; emix=emix+1)
{
printf ("%.1f\n", emix) | scan (es)
quickclust.egalmix=emix

# more fudge! this is roughly based on CWW SEDs (hyperz)
if (emix==0.)
{
if (z <= 2.00) kcorr = 0.8
if (z <= 1.75) kcorr = 0.8
if (z <= 1.50) kcorr = 0.8
if (z <= 1.25) kcorr = 0.8
if (z <= 1.00) kcorr = 0.7
if (z <= 0.75) kcorr = 0.6
if (z <= 0.50) kcorr = 0.5
if (z <= 0.25) kcorr = 0.4
}
if (emix==1.)
{
if (z <= 2.00) kcorr = 1.1
if (z <= 1.75) kcorr = 0.9
if (z <= 1.50) kcorr = 1.1
if (z <= 1.25) kcorr = 1.1
if (z <= 1.00) kcorr = 0.9
if (z <= 0.75) kcorr = 0.8
if (z <= 0.50) kcorr = 0.7
if (z <= 0.25) kcorr = 0.5
} hstar = kstar + kcorr
quickclust.mstar=hstar for (i=1; i<=imax; i=i+1)
{
printf ("%02.0f\n", i) | scan (is)
outstr = "cluster_z"//zs//"_n"//ns//"_e"//es//"_i"//is
print (outstr)

quickclust
rename (clist, outstr//".in")
rename (climg, outstr//".fits")
} } } }>From valdes Tue Oct 23 15:16:05 2001
Date: Tue, 23 Oct 2001 15:16:04 -0700 (MST)
From: Frank Valdes <valdes>
To: fitz, zarate
Subject: Re: mkobjects on PC-IRAFThis logs what I have done in trying to trace the problem. I don't plan
to pursue this further but if someone else wants to then this information
will be helpful.The test case is on vmware in the login directory of itest1. I have reduced
the problem to a script that only calls the x_artdata.e executable. This
script is doit.cl. When run with LOGIPC it produces the file needed to
run the process standalone. The file artdata.in provides this. For each
run you must first delete all cluster_z* files.
itest1@vmware% setenv LOGIPC
itest1&vmware% cl
cl> cl <doit.cl
cluster_z0.50_n010_e0.0_i01.fits
cluster_z0.50_n010_e0.0_i02.fits
cluster_z0.50_n010_e0.0_i03.fits
cluster_z0.50_n010_e0.0_i04.fits
cluster_z0.50_n010_e0.0_i05.fits
cluster_z0.50_n010_e0.0_i06.fitsPANIC in `/iraf/iraf/noao/bin.redhat/x_artdata.e': segmentation violation
cluster_z0.50_n010_e0.0_i07.fits
ERROR: Abnormal termination of child process 'noaobin$x_artdata.e'
cl ()
cl ()
cl> flprFind the last *.in file which is the one for the x_artdata.e process.
itest1@vmware% rm cluster_z*
itest1@vmware% gdb /iraf/iraf/noao/bin.redhat/x_artdata.e
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r -c <artdata.in
Starting program: /iraf/iraf/noao/bin.redhat/x_artdata.e -c <artdata.in
bye
P=ranbuf
P
=nxc
P
=nyc
P=nxsub
P=nysub
P=nxgsub
P=nygsub
P=dynrange
P=psfrange
bye
bye
P=ranbuf
P
=nxc
P
=nyc
P=nxsub
P=nysub
P=nxgsub
P=nygsub
P=dynrange
P=psfrangeProgram received signal SIGSEGV, Segmentation fault.
0x4008d5fb in chunk_alloc (ar_ptr=0x40122040, nb=521232) at malloc.c:2748
2748 malloc.c: No such file or directory.
(gdb) where
#0 0x4008d5fb in chunk_alloc (ar_ptr=0x40122040, nb=521232) at malloc.c:2748
#1 0x4008d40a in __libc_malloc (bytes=521222) at malloc.c:2643
#2 0x8130071 in zmaloc_ ()
#3 0x8112b25 in mallo1_ ()
#4 0x8124e87 in vmallc_ ()
#5 0x811e067 in fmkbfs_ ()
#6 0x80fc57a in fwritp_ ()
#7 0x8089d3d in impl2r_ ()
#8 0x8058e4c in tmkobs_ ()
#9 0x804a124 in sysruk_ ()
#10 0x810daa0 in irafmn_ ()
#11 0x8081bcc in main ()
#12 0x4004d1eb in __libc_start_main (main=0x80817f0 <main>, argc=2,
argv=0xbffffa14, init=0x80495ac <_init>, fini=0x813193c <_fini>,
rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffa0c)
at ../sysdeps/generic/libc-start.c:90
(gdb) The impl2r call is on line 421 of t_mkobjects.x. This did not fail when
I relinked for debugging. Adding print statements also changes the behavior
though usually it will fail but after a different number of iterations.
Note that even using the LOGIPC to reproduce the execution environment as
closely as possible the failure occurs in different places in the above.One test I did was to run the same script with imh files and there was no
error. I don't blame the FK but somewhere uninitialized memory is being
used. I think this problem may be related to doing read-write operations
to the output image.Frank

 
Anonymous: Guest
 10/17/2001 04:00PM  



>From valdes Tue Oct 23 15:16:05 2001
Date: Tue, 23 Oct 2001 15:16:04 -0700 (MST)
From: Frank Valdes <valdes>
To: fitz, zarate
Subject: Re: mkobjects on PC-IRAFThis logs what I have done in trying to trace the problem. I don't plan
to pursue this further but if someone else wants to then this information
will be helpful.The test case is on vmware in the login directory of itest1. I have reduced
the problem to a script that only calls the x_artdata.e executable. This
script is doit.cl. When run with LOGIPC it produces the file needed to
run the process standalone. The file artdata.in provides this. For each
run you must first delete all cluster_z* files.
itest1@vmware% setenv LOGIPC
itest1&vmware% cl
cl> cl <doit.cl
cluster_z0.50_n010_e0.0_i01.fits
cluster_z0.50_n010_e0.0_i02.fits
cluster_z0.50_n010_e0.0_i03.fits
cluster_z0.50_n010_e0.0_i04.fits
cluster_z0.50_n010_e0.0_i05.fits
cluster_z0.50_n010_e0.0_i06.fitsPANIC in `/iraf/iraf/noao/bin.redhat/x_artdata.e': segmentation violation
cluster_z0.50_n010_e0.0_i07.fits
ERROR: Abnormal termination of child process 'noaobin$x_artdata.e'
cl ()
cl ()
cl> flprFind the last *.in file which is the one for the x_artdata.e process.
itest1@vmware% rm cluster_z*
itest1@vmware% gdb /iraf/iraf/noao/bin.redhat/x_artdata.e
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r -c <artdata.in
Starting program: /iraf/iraf/noao/bin.redhat/x_artdata.e -c <artdata.in
bye
P=ranbuf
P
=nxc
P
=nyc
P=nxsub
P=nysub
P=nxgsub
P=nygsub
P=dynrange
P=psfrange
bye
bye
P=ranbuf
P
=nxc
P
=nyc
P=nxsub
P=nysub
P=nxgsub
P=nygsub
P=dynrange
P=psfrangeProgram received signal SIGSEGV, Segmentation fault.
0x4008d5fb in chunk_alloc (ar_ptr=0x40122040, nb=521232) at malloc.c:2748
2748 malloc.c: No such file or directory.
(gdb) where
#0 0x4008d5fb in chunk_alloc (ar_ptr=0x40122040, nb=521232) at malloc.c:2748
#1 0x4008d40a in __libc_malloc (bytes=521222) at malloc.c:2643
#2 0x8130071 in zmaloc_ ()
#3 0x8112b25 in mallo1_ ()
#4 0x8124e87 in vmallc_ ()
#5 0x811e067 in fmkbfs_ ()
#6 0x80fc57a in fwritp_ ()
#7 0x8089d3d in impl2r_ ()
#8 0x8058e4c in tmkobs_ ()
#9 0x804a124 in sysruk_ ()
#10 0x810daa0 in irafmn_ ()
#11 0x8081bcc in main ()
#12 0x4004d1eb in __libc_start_main (main=0x80817f0 <main>, argc=2,
argv=0xbffffa14, init=0x80495ac <_init>, fini=0x813193c <_fini>,
rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffa0c)
at ../sysdeps/generic/libc-start.c:90
(gdb) The impl2r call is on line 421 of t_mkobjects.x. This did not fail when
I relinked for debugging. Adding print statements also changes the behavior
though usually it will fail but after a different number of iterations.
Note that even using the LOGIPC to reproduce the execution environment as
closely as possible the failure occurs in different places in the above.One test I did was to run the same script with imh files and there was no
error. I don't blame the FK but somewhere uninitialized memory is being
used. I think this problem may be related to doing read-write operations
to the output image.Frank

 
   

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login