[taste-users] TASTE Wrapper Code Leading to Constraint Error

[Gert Caspersen <gec@xxxxxxxxx>]

                Hi Thanassis & Maxime,

 

I have now encountered a new problem with the generated TASTE code. Please see the enclosed extract from our problem database.

 

Any suggestions are highly appreciated.

 

                Regards,

 

                                Gert

Gert Caspersen
Senior Engineer, Project Manager
Space Projects (DK)
Space

Terma A/S
Vasekær 12
2730 Herlev
Denmark

T +45 8743 6000
T +45 4594 9653 (direct)
F +45 8743 6001
E gec@xxxxxxxxx
W www.terma.com

---

Attention:
This e-mail (and attachment(s), if any) - intended for the addressee(s) only - may contain confidential, copyright, or legally privileged information or material, and no one else is authorized to read, print, store, copy, forward, or otherwise use or disclose any part of its contents or attachment(s) in any form. If you have received this e-mail in error, please notify me by telephone or return e-mail, and delete this e-mail and attachment(s). Thank you.

Title: [#MBCODE-11] TASTE Wrapper Code Leading to Constraint Error

<< Back to previous view

[MBCODE-11] TASTE Wrapper Code Leading to Constraint Error Created: 2012.05.30  Updated: 2012.05.30
Status:	Open
Project:	Model Based Component Development
Component/s:	None
Affects Version/s:	None
Fix Version/s:	None
Security Level:	Public Issue (Issue visible to all project affiliates (i.e. members and observers).)

Type:	Problem Report	Priority:	Blocker
Reporter:	Gert Caspersen	Assignee:	Gert Caspersen
Resolution:	Unresolved	Votes:	0
Labels:	None
Remaining Estimate:	Not Specified
Time Spent:	Not Specified
Original Estimate:	Not Specified
Environment:	Revision 139 TASTE Build 120516

Description

During execution of the Onboard_Monitoring demonstrator, the following exception is raised:

raised CONSTRAINT_ERROR : parameterpool.adb:30 discriminant check failed

The exception is raised on the assignment statement in the following manually generated code:

parameterpool.adb

procedure getParameter (id : access asn1sccParameter_ID; currentvalue : access asn1sccParameter_Value) is
   begin

      currentvalue.all :=  thePool(id.all);

   end getParameter;

The type asn1sccParameter_Value is defined as follows:

onboard_parameters.ads

TYPE asn1SccParameter_Value_selection IS (type_1_0_PRESENT, type_1_1_PRESENT);
for asn1SccParameter_Value_selection use
	(type_1_0_PRESENT => 1, type_1_1_PRESENT => 2);
for asn1SccParameter_Value_selection'Size use 32;

TYPE asn1SccParameter_Value(kind : asn1SccParameter_Value_selection := type_1_0_PRESENT) IS 
RECORD
    case kind is
    when type_1_0_PRESENT =>
            type_1_0: asn1SccUnsigned_Integer;
    when type_1_1_PRESENT =>
            type_1_1: asn1SccUnsigned_Integer;
    end case;
END RECORD;

FOR asn1SccParameter_Value USE 
RECORD
	kind AT 0 RANGE 0..31;
END RECORD;

Valid 'raw' values for the discriminant is thus 1 and 2. The wrapper code generated for the call to getParameter defines a local variable OUT_currentvalue that is intended to hold the result. This value is initally filled with zeros on the Linux platform only as shown below:

parameter_pool_vm_if.c

#ifdef __unix__
	memset(&IN_id, 0, sizeof(asn1SccParameter_ID));
	memset(&OUT_currentvalue, 0, sizeof(asn1SccParameter_Value));
#endif

	/* Decode each input parameter */
	if (0 != Decode_NATIVE_Parameter_ID (&IN_id, pmy_id, size_my_id)) {
		printf("\nError Decoding Parameter_ID\n");
		return;
	}

	/* Call to User-defined function */
	parameterpool_PI_getParameter (&IN_id, &OUT_currentvalue);

The 'de-referencing' performed by currentvalue.all in getParameter will check for the validity of the discriminant. This has been flushed to the value 0 (zero), which is not a legal discriminant value, thus leading to the constraint error.

Generated at Wed May 30 15:59:25 CEST 2012 by Gert Caspersen using JIRA 4.4#649-r158309.