View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

immatch invalid pointer

kanaan wrote on Oct 06, 2009

On suse 11.0 (or 11.1) and iraf 2.14.1

I reinstalled ctio, recompiling from scratch. When I run immatch:

(I would appreciate any suggestions on how to fix this :-)

*** glibc detected *** /iraf/extern/ctio/bin.linux/x_ctio.e: free(): invalid pointer: 0x082d28f0 ***
======= Backtrace: =========
/lib/libc.so.6[0x400affc4]
/lib/libc.so.6(cfree+0x9c)[0x400b195c]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x8160555]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x81318c2]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x8131c97]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x80552c2]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x804ab16]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x812c410]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x809a599]
/lib/libc.so.6(__libc_start_main+0xe5)[0x4005a5f5]
/iraf/extern/ctio/bin.linux/x_ctio.e[0x804a431]
======= Memory map: ========
08048000-08167000 r-xp 00000000 08:08 9373945 /home/iraf/extern/ctio/bin.linux/x_ctio.e
08167000-08168000 r-xp 0011e000 08:08 9373945 /home/iraf/extern/ctio/bin.linux/x_ctio.e
08168000-0818b000 rwxp 0011f000 08:08 9373945 /home/iraf/extern/ctio/bin.linux/x_ctio.e
0818b000-0835a000 rwxp 0818b000 00:00 0 [heap]
40000000-4001b000 r-xp 00000000 08:06 423494 /lib/ld-2.8.so
4001b000-4001c000 r-xp 0001a000 08:06 423494 /lib/ld-2.8.so
4001c000-4001d000 rwxp 0001b000 08:06 423494 /lib/ld-2.8.so
4001d000-4001e000 rwxp 4001d000 00:00 0
4001e000-40042000 r-xp 00000000 08:06 423509 /lib/libm-2.8.so
40042000-40043000 r-xp 00023000 08:06 423509 /lib/libm-2.8.so
40043000-40044000 rwxp 00024000 08:06 423509 /lib/libm-2.8.so
40044000-40181000 r-xp 00000000 08:06 423501 /lib/libc-2.8.so
40181000-40183000 r-xp 0013d000 08:06 423501 /lib/libc-2.8.so
40183000-40184000 rwxp 0013f000 08:06 423501 /lib/libc-2.8.so
40184000-401aa000 rwxp 40184000 00:00 0
401aa000-401b6000 r-xp 00000000 08:06 423594 /lib/libgcc_s.so.1
401b6000-401b7000 r-xp 0000b000 08:06 423594 /lib/libgcc_s.so.1
401b7000-401b8000 rwxp 0000c000 08:06 423594 /lib/libgcc_s.so.1
401ca000-401d3000 r-xp 00000000 08:06 423518 /lib/libnss_files-2.8.so
401d3000-401d4000 r-xp 00008000 08:06 423518 /lib/libnss_files-2.8.so
401d4000-401d5000 rwxp 00009000 08:06 423518 /lib/libnss_files-2.8.so
401d5000-401dc000 r-xp 00000000 08:06 423514 /lib/libnss_compat-2.8.so
401dc000-401dd000 r-xp 00006000 08:06 423514 /lib/libnss_compat-2.8.so
401dd000-401de000 rwxp 00007000 08:06 423514 /lib/libnss_compat-2.8.so
401de000-401f1000 r-xp 00000000 08:06 423512 /lib/libnsl-2.8.so
401f1000-401f2000 r-xp 00012000 08:06 423512 /lib/libnsl-2.8.so
401f2000-401f3000 rwxp 00013000 08:06 423512 /lib/libnsl-2.8.so
401f3000-401f5000 rwxp 401f3000 00:00 0
401f5000-401fd000 r-xp 00000000 08:06 423522 /lib/libnss_nis-2.8.so
401fd000-401fe000 r-xp 00007000 08:06 423522 /lib/libnss_nis-2.8.so
401fe000-401ff000 rwxp 00008000 08:06 423522 /lib/libnss_nis-2.8.so
401ff000-40298000 rwxp 401ff000 00:00 0
40300000-40321000 rwxp 40300000 00:00 0
40321000-40400000 ---p 40321000 00:00 0
bfe7d000-bfe92000 rwxp bffeb000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

thanks,

Antonio

Mike Fitzpatrick wrote on Oct 06, 2009

The message simply means there was a memory error of some kind, but without the parameters and perhaps the images you used it isn't possible to say exactly what happened. The CTIO package was orphaned long ago and you might look at tasks in the IMAGES.IMMATCH package for alternatives.

-Mike

kanaan wrote on Oct 06, 2009

Hi Mike,

thanks for your reply. You have already in the past advised me to abandon ctio.immatch and I stubbornly refused to do that. I had some time today to look at the immatch package.

xregister seems to be the closest thing to good old ctio.immatch. Still, not the same thing as it does a 2D crosscor on 2d images, not 2 1D crosscors as ctio.immatch - this is too slow for me.

The solution I see at the moment is to create a new function that collapses each of my 2 2D images into two 1D images and then run xregister twice on the two pairs of images. This would in the end do the same as ctio.immatch.

If you can see a simpler way of doing this please let me know.

thanks,

Antonio

kanaan wrote on Oct 06, 2009

here I am back to the ctio package. Mike, you said it has been orphaned, but as it is included in 2.15 extern packages I decided to give it a try :-)

I tried to compile it (I did compile tables with no problems):

hal> mkpkg -p ctio
envinit: cannot open `/iraf/extern/ctio/lib/zzsetenv.def'
Warning, mkpkg line 0: cannot open `ctio$lib/mkpkg.inc'
warning: library `libpkg.a' not found
xc -c -w -/g -/m64 getentry.x getradii.x hdr.x icntr.x lfit.f peaks.x rngfit.f simul.f t_avgvel.x t_findsky.x t_fitring.x t_icntr.x t_mkcube.x t_mkshift.x t_normalize.x t_ringpars.x t_velocity.x t_zeropt.x
getentry.x:
get_next_entry:
rst_get_entry:
getradii.x:
get_radii:
hdr.x:
ids_hdri:
ids_hdrr:
get_hdrr:
ids_addi:
ids_addr:
ids_sex:
ids_adds:

...

velint:
olamre:
lamrae:
t_zeropt.f:
tzerot:
lambd0:
ar r /home/iraf64/extern/ctio/fabry/libpkg.a getentry.o getradii.o hdr.o icntr.o lfit.o peaks.o rngfit.o simul.o t_avgvel.o t_findsky.o t_fitring.o t_icntr.o t_mkcube.o t_mkshift.o t_normalize.o t_ringpars.o t_velocity.o t_zeropt.o
ar: creating /home/iraf64/extern/ctio/fabry/libpkg.a
ranlib libpkg.a
Updated 18 files in libpkg.a
xc -c -w -/g -/m64 x_fabry.x
x_fabry.x:
sys_runtask:
x_fabry.f:
sysruk:
xc -Nz -/g -/m64 x_fabry.o libpkg.a -lxtools -o xx_fabry.e
move `xx_fabry.e' to `pkgbin$x_fabry.e'
purge directory `pkgbin$'
warning: library `libpkg.a' not found
Warning, mkpkg line 27: dependency file `<idsmtn.h>' not found
xc -c -w -/g -/m64 comrebin.x debug.x edit.x expscale.x idsm_keywrds.x lam2pix.x load_hdr.x plot.x rebin.x setdef.x sort.x spcombine.x struct.x t_spcombine.x
comrebin.x:
rebin_spectra:
rebin_adjust:

...

sphot1:
photoy:
xyerrr:
photer:
ar r /home/iraf64/extern/ctio/src/libpkg.a photom.o radius2.o t_sphot.o value.o xysetup.o
xc -c -w -/g -/m64 t_statspec.x
t_statspec.x:
t_statspec:
t_statspec.f:
tstatc:
ar r /home/iraf64/extern/ctio/src/libpkg.a t_statspec.o
xc -c -w -/g -/m64 t_wairmass.x
t_wairmass.x:
t_wairmass:
wrm_gethdr:
t_wairmass.f:
twairs:
wrmger:
ar r /home/iraf64/extern/ctio/src/libpkg.a t_wairmass.o
ranlib libpkg.a
Updated 147 files in libpkg.a
xc -c -w -/g -/m64 x_ctio.x
x_ctio.x:
sys_runtask:
x_ctio.f:
sysruk:
xc -Nz -/g -/m64 x_ctio.o libpkg.a -lxtools -lcurfit -liminterp -o xx_ctio.e
x_ctio.o: In function `sysruk_':
/home/iraf64/extern/ctio/src/x_ctio.x:180: undefined reference to `tchpie_'
collect2: ld returned 1 exit status
Warning, mkpkg line 7: module `relink' not found or returned error
move `xx_ctio.e' to `pkgbin$x_ctio.e'
$move: file `xx_ctio.e' not found
Warning, mkpkg line 20: error moving file xx_ctio.e
purge directory `pkgbin$'

thanks,

Antonio

Mike Fitzpatrick wrote on Oct 06, 2009


hal> mkpkg -p ctio
envinit: cannot open `/iraf/extern/ctio/lib/zzsetenv.def'
Warning, mkpkg line 0: cannot open `ctio$lib/mkpkg.inc'


This usually means the package directory wasn't declared in the hlib$extern.pkg file (or was declared incorrectly). Since 'mkpkg' is actually a foreign command, the only place it gets the value of 'ctio' is from the unix environment or the extern.pkg file, setting it in the CL environment on the commandline won't do it.

Note the package is abandoned in the sense there is not much effort going to go into debugging hard memory bugs, but as long as the code still compiles with minimal effort we'll still distribute it.

Cheers,
-Mike

kanaan wrote on Oct 06, 2009

allright, problem fixed.

I have

setenv iraf /home/iraf64/iraf

in the extern.pkg file that came with the distribution it says:

reset noao = iraf$noao/
task noao.pkg = noao$noao.cl

reset tables = iraf$tables/
task tables.pkg = tables$tables.cl

reset stsdas = /iraf/extern/stsdas/
task stsdas.pkg = stsdas$stsdas.cl

reset nlocal = /iraf/extern/nlocal/
task nlocal.pkg = nlocal$nlocal.cl

reset ctio = /iraf/extern/ctio/
task ctio.pkg = ctio$ctio.cl

This looks strange to me, why is noao listed as an extern package? Its location is correctly pointed by

reset noao = iraf$noao/

now, tables is referred as:

reset tables = iraf$tables/
task tables.pkg = tables$tables.cl

living at the same level as noao.

Now, all other packages are pointed to by:

/iraf/extern

which in my case ain't true. To make it work I simply made a symbolic link:

ln -s /home/iraf64 /iraf

and I also put my iraf environment variable to /iraf/iraf

the question is I want to keep more than one install of iraf, like the good, the bad and the ugly :-) and doing this link forces me to change the link whenever I want to run a different iraf.

Anyway, it looks fishy, hope this message is useful

Antonio

Mike Fitzpatrick wrote on Oct 06, 2009

That is all normal. In order to have a working core IRAF, those tasks that rely on TABLES needed a 64-bit TABLES package, hence the version in iraf$tables. If you built your own tables from source and linked packages against it I can guarantee things will break, use the iraf$tables version.

Otherwise, NOAO has always been an external package, just one distributed with the rest of the system.

Last post on Oct 06, 2009