From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,4590cbe206fc9bb9,start
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.224.111.8 with SMTP id q8mr1844861qap.3.1346960076468;
        Thu, 06 Sep 2012 12:34:36 -0700 (PDT)
Received: by 10.52.156.115 with SMTP id wd19mr628673vdb.2.1346960076429; Thu,
 06 Sep 2012 12:34:36 -0700 (PDT)
Path: 
 da15ni476693qab.0!nntp.google.com!v8no1349709qap.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 6 Sep 2012 12:34:36 -0700 (PDT)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=192.31.106.34;
 posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j
NNTP-Posting-Host: 192.31.106.34
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6dfcb108-01de-42e4-962a-87a9ac91741c@googlegroups.com>
Subject: Stumped: Seg Fault with System.Secondary_Stack.SS_Mark()
From: awdorrin <awdorrin@gmail.com>
Injection-Date: Thu, 06 Sep 2012 19:34:36 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 2012-09-06T12:34:36-07:00
List-Id: <comp.lang.ada>

I am getting some random seg faults from my program:

system.secondary_stack.ss_mark () at s-secsta.adb:467

and I'm at a loss for what is going on. I'm guessing that GNAT thinks the s=
tack is bad when the call is made.

The backtrace of my code is:

#0  system.secondary_stack.ss_mark () at s-secsta.adb:467
#1  0x081ec693 in r_de.get_de_int (de_num=3D79500, to_unit=3Dnone)
    at /home/aldorr/lasis/code/rtsim/rde_b.ada:2288
#2  0x081244b8 in g_sv.svs_get_value (svs_num=3D79500) at ../code/common/gs=
v_b.ada:172
#3  0x082e867b in sc_mfr.execute () at ../code/sensor/comm/scmfr_b.ada:4627
#4  0x080ff25f in execute_senctl () at ../code/rtctl/esnctl_b.ada:589
#5  0x08050fe2 in e_sequencer (e_cycle_count=3D56707) at e_seq.c:511
#6  0x080efb92 in e_mainline.exec_subfunctions () at ../code/rtctl/e_mainli=
ne_b.ada:453
#7  0x080f044e in e_mainline.exec_main_line_normal () at ../code/rtctl/e_ma=
inline_b.ada:697
#8  0x080ee726 in e_mainline () at ../code/rtctl/e_mainline_b.ada:771
#9  0x080536ba in rtctl_rts () at gosim.c:380
#10 0xb7a198a6 in task_wrapper (task=3D0x8aa5310) at ltaskLib.c:669
#11 0xb7fba955 in start_thread (arg=3D0xb663fb70) at pthread_create.c:300
#12 0xb797c5ee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Looking at the assembly at Frame 1:

0x81ec677 <r_de__get_de_int>    push   %ebp
0x81ec678 <r_de__get_de_int+1>  mov    %esp,%ebp
0x81ec67a <r_de__get_de_int+3>  push   %esi
0x81ec67b <r_de__get_de_int+4>  push   %ebx
0x81ec67c <r_de__get_de_int+5>  sub    $0xb0,%esp
0x81ec682 <r_de__get_de_int+11> mov    0xc(%ebp),%eax
0x81ec685 <r_de__get_de_int+14> mov    %al,-0x5c(%ebp)
0x81ec688 <r_de__get_de_int+17> lea    -0x68(%ebp),%eax
0x81ec68b <r_de__get_de_int+20> mov    %eax,(%esp)
0x81ec68e <r_de__get_de_int+23> call   0x804e908 <system__secondary_stack__=
ss_mark@plt>=20
0x81ec693 <r_de__get_de_int+28> sub    $0x4,%esp =20

Then the assembly at Frame 0:

0xb7e180e0 <system__secondary_stack__ss_mark>           push   %ebp
0xb7e180e1 <system__secondary_stack__ss_mark+1>         mov    %esp,%ebp
0xb7e180e3 <system__secondary_stack__ss_mark+3>         sub    $0x8,%esp
0xb7e180e6 <system__secondary_stack__ss_mark+6>         mov    %ebx,(%esp)
0xb7e180e9 <system__secondary_stack__ss_mark+9>         call   0xb7cb0ca7 <=
__i686.get_pc_thunk.bx>
0xb7e180ee <system__secondary_stack__ss_mark+14>        add    $0x9748a,%eb=
x
0xb7e180f4 <system__secondary_stack__ss_mark+20>        mov    %esi,0x4(%es=
p)
0xb7e180f8 <system__secondary_stack__ss_mark+24>        mov    0x8(%ebp),%e=
si
0xb7e180fb <system__secondary_stack__ss_mark+27>        mov    -0x298(%ebx)=
,%eax
0xb7e18101 <system__secondary_stack__ss_mark+33>        call   *(%eax)
0xb7e18103 <system__secondary_stack__ss_mark+35>        mov    (%eax),%edx

I can tell that the 'GET_DE_INT' function call hasn't even gotten to the fi=
rst line of code within the function, but I'm really not sure what is going=
 on. The data structures themselves look fine. So I'm not sure if GNAT thin=
ks I'm blowing the stack, or what.

My assembly knowledge is more than a little rusty... :)

The corresponding Ada code is:
Frame 2:

DE_NUM :=3D R_DE.DE_NUM_TYPE'val(SVS_NUM);
TEMP   :=3D R_DE.GET_DE_INT(DE_NUM);

Then in Frame 1:

function GET_DE_INT
  (DE_NUM: DE_NUM_TYPE;
   TO_UNIT : R_CONVERT.UNIT_TYPE :=3D R_CONVERT.NONE )
  return INT32 is
  DE_VAL_FLT : FLOAT64;
  RC : INT32;
begin
  GET_DE( DE_NUM, DE_DATA(DE_NUM).ADDR, TO_UNIT, DE_VAL_FLT, RC );


At the time of the crash, I don't think the GET_DE_INT function has even go=
tten as far as validating the parameters (since I see some __gnat_rcheck ca=
lls further down in the assembly code)

Anyone have any suggestions on what I can look at?

Thanks!