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
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.224.39.75 with SMTP id f11mr1964266qae.8.1346964791456;
        Thu, 06 Sep 2012 13:53:11 -0700 (PDT)
Received: by 10.52.28.83 with SMTP id z19mr686808vdg.20.1346964791406; Thu, 06
 Sep 2012 13:53:11 -0700 (PDT)
Path: 
 da15ni851qab.0!nntp.google.com!b19no1294418qas.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 6 Sep 2012 13:53:11 -0700 (PDT)
In-Reply-To: <87fw6u2abw.fsf@ludovic-brenta.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=192.91.171.34;
 posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j
NNTP-Posting-Host: 192.91.171.34
References: <6dfcb108-01de-42e4-962a-87a9ac91741c@googlegroups.com>
 <87fw6u2abw.fsf@ludovic-brenta.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <016ff78a-64f9-4a42-a079-e544526e2f8a@googlegroups.com>
Subject: Re: Stumped: Seg Fault with System.Secondary_Stack.SS_Mark()
From: awdorrin <awdorrin@gmail.com>
Injection-Date: Thu, 06 Sep 2012 20:53:11 +0000
Content-Type: text/plain; charset=ISO-8859-1
Date: 2012-09-06T13:53:11-07:00
List-Id: <comp.lang.ada>

The -gnatDG results, for the function in question:

   function r_de__get_de_int (de_num : in r_de__de_num_type; to_unit :
     in r_convert.r_convert__unit_type := r_convert.r_convert__none)
     return global_types__int32 is
      M875b : system__secondary_stack__mark_id :=
        $system__secondary_stack__ss_mark;

      procedure r_de__get_de_int___clean is
      begin
         $system__secondary_stack__ss_release (M875b);
         return;
      end r_de__get_de_int___clean;
   begin
      de_val_flt : global_types__float64;
      rc : global_types__int32;
      [constraint_error when
        r_de__de_data = null
        "access check failed"]
      [constraint_error when
        not (r_de__Tde_num_typeB(de_num) in 1 .. r_de__de_data.all'last)
        "index check failed"]
      r_de__get_de (de_num, r_de__de_data.all (de_num).addr, to_unit,
        de_val_flt, rc);
      if rc /= 0 then
         subtype r_de__get_de_int__TS863bS is string (1 .. 11);
         S863b : string (1 .. 11);
         P864b : natural;
         $system__img_int__image_integer (integer(rc), S863b, P864b);
         R865b : constant natural := P864b;
         B869b : declare
         begin
            g_error.g_error__add_to_q ($system__string_ops__str_concat
              ("R_DE.GET_DE_INT: FAILED.  RC = ", S863b (1 .. R865b)),
              error_type => g_common.g_common__non_severe);
         end B869b;
         if rc = -1 then
            $__gnat_raise_exception (ada__exceptions__exception_id!(
              r_de__illegal_conversion'reference), "rde_b.ada:2305");
         elsif rc = -2 then
            $__gnat_raise_exception (ada__exceptions__exception_id!(
              r_de__get_de_exception'reference), "rde_b.ada:2308");
         end if;
      end if;
      [constraint_error when
        not (de_val_flt > (-(4503599628419072.0*2**(-21))) and then
          de_val_flt < (9007199252643840.0*2**(-22)))
        "overflow check failed"]
      return global_types__int32(de_val_flt);
   at end
      r_de__get_de_int___clean;
   end r_de__get_de_int;


I'm still not sure what to make of that...

Could GNAT be misinterpreting the 'int32' return type? (Global_Types.Int32 is defined as: subtype INT32 is Integer;)

Or could the 'DE_DATA' structure be causing the issues?

It is defined as in the 'rde_b.ada' file as:

type DE_ARRAY_TYPE is array (DE_NUM_TYPE range <>) of DE_REC_TYPE;
NUM_DES: constant INT32 := G_COMMON.NUM_LINES(DE_CFG_FN);
subtype CONSTRAINED_DE_ARRAY is DE_ARRAY_TYPE( DE_NUM_TYPE range 1 .. DE_NUM_TYPE(NUM_DES));
type DE_ARRAY_PTR_TYPE is access all CONSTRAINED_DE_ARRAY;
DE_DATA : DE_ARRAY_PTR_TYPE;

DE_DATA is a pointer to memory allocated by another process (The original developers allocated memory in a HeapMgr package they developed...)

I just don't know if this legacy goofiness with the heapmgr allocating memory is incompatible with the newer Ada95/2005 approaches... or if I'm getting side tracked from the real problem.