Hi Tim.
I'll have a go at rsyncing JACs starlink, though I should get my MSBs
remade first before breaking anything else!
results of the bt command follow.
Cheers
Dave
daedalus spxdjn 215: gdb $SMURF_DIR/sc2clean
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 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 "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/libthread_db.so.1".
(gdb) run concat.sdf clean order=0 dcbox=50
Starting program: /home/soft/star-hawaiki/star64/bin/smurf/sc2clean
concat.sdf clean order=0 dcbox=50
[Thread debugging using libthread_db enabled]
[New Thread 46917776365200 (LWP 17836)]
[New Thread 1115605312 (LWP 17914)]
[New Thread 1126095168 (LWP 17915)]
[Detaching after fork from child process 17916. (Try `set detach-on-fork off'.)]
Processing data from instrument 'SCUBA-2' for object 'URANUS' from the
following observation :
20091214 #15 scan
[Detaching after fork from child process 17917.]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46917776365200 (LWP 17836)]
smf_begin_job_context (workforce=0x0, status=0x7fff7326df1c)
at smf_threads.c:702
702 smf_threads.c: No such file or directory.
in smf_threads.c
(gdb) bt
#0 smf_begin_job_context (workforce=0x0, status=0x7fff7326df1c)
at smf_threads.c:702
#1 0x000000000046c53f in smf_correct_steps (wf=0x0, data=0x2c618f8,
quality=0x0, dcthresh=150, dcthresh2=10, dcbox=50, dcflag=0, nsteps=0x0,
status=0x7fff7326df1c) at smf_correct_steps.c:313
#2 0x00000000004339c6 in smurf_sc2clean (status=0x7fff7326df1c)
at smurf_sc2clean.c:317
#3 0x000000000040cd6c in smurf_mon (status=0x7fff7326df1c) at smurf_mon.c:283
#4 0x000000000040cf48 in dtask_wrap_ (fstatus=0x7fff7326e298)
at dtask_wrap.c:8
#5 0x000000000040c697 in dtask_applic_ (context=<value optimized out>,
actcode=<value optimized out>, aname=<value optimized out>,
actptr=<value optimized out>, seq=0x7fff7326dff0,
value=0x7fff7326e040 "concat.sdf clean order=0 dcbox=50", ' '
<repeats 167 times>..., schedtime=0x7fff7326dff4,
request=0x7fff7326dfec,
status=0x7fff7326e298, aname.len=0, value.len=444) at dtask_applic.f:71
#6 0x00002aabe2656bb0 in dtask_obeydcl_ (
dtask_applic=0x40c5e0 <dtask_applic_>, name=<value optimized out>,
value=0x7fff7326e040 "concat.sdf clean order=0 dcbox=50", ' '
<repeats 167 times>..., status=0x7fff7326e298, name.len=<value
optimized out>, value.len=444)
at dts_obeydcl.f:160
#7 0x00002aabe26553c8 in dtask_dcltask_ (devinit=0x40c5d0 <devinit_>,
dtask_applic=0x40c5e0 <dtask_applic_>, status=0x7fff7326e298)
---Type <return> to continue, or q <return> to quit---
at dts_dcltask.f:153
#8 0x000000000040c5c1 in MAIN_ () at dtask_main.f:140
#9 0x00000000005ab41e in main ()
(gdb)
On Wed, Feb 17, 2010 at 6:52 AM, Tim Jenness <[log in to unmask]> wrote:
> The good news is that the current version of SMURF does not have a problem.
> The bad news is that I'm not sure which patch fixed it. The even worse news
> is that SMURF has changed a lot since hawaiki was released and so real
> shared-risks data may not reduce with the hawaiki version. Can you rsync the
> live JAC version? (obviously not tonight since the JAC servers are all
> off-line).
>
> Can you tell me where the crash is happening?
>
> % gdb $SMURF_DIR/sc2clean
> gdb> run concat.sdf clean order=0 dcbox=50
> gdb> bt
>
> and send me the output of the "bt" command.
>
> Tim
>
> On Mon, Feb 15, 2010 at 1:58 AM, David Nutter <[log in to unmask]>
> wrote:
>>
>> Hi.
>>
>> I'm getting a seg fault with sc2clean whilst running through the
>> cookbook commands (with the sample data from JAC).
>> This error appears on both 64- and 32-bit linux running Hawaiki. The
>> command works until dcbox=50 is added. the input file is produced by
>> concatenating
>> s4a20091214_00015_0002.sdf and s4a20091214_00015_0003.sdf.
>>
>> daedalus spxdjn 235: sc2clean concat.sdf clean order=0
>> Processing data from instrument 'SCUBA-2' for object 'URANUS' from the
>> following observation :
>> 20091214 #15 scan
>>
>> daedalus spxdjn 236: sc2clean concat.sdf clean order=0 dcbox=50
>> Processing data from instrument 'SCUBA-2' for object 'URANUS' from the
>> following observation :
>> 20091214 #15 scan
>>
>> Segmentation fault
>>
>> daedalus spxdjn 237: sc2clean concat.sdf clean order=0 dcbox=50
>> dcthresh=200 dcflagall fillgaps
>> Processing data from instrument 'SCUBA-2' for object 'URANUS' from the
>> following observation :
>> 20091214 #15 scan
>>
>> Segmentation fault
>>
>>
>> Cheers
>> Dave
>
>
