titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2022-09-21T13:23:43Zhttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/481Faulty subtype checking2022-09-21T13:23:43ZEclipse WebmasterFaulty subtype checking## Submitted by Gabor Szalai
**[Link to original bug (#562085)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562085)**
## Description
The following subtyping is a valid according to the standard but not accepted by the TI...## Submitted by Gabor Szalai
**[Link to original bug (#562085)](https://bugs.eclipse.org/bugs/xmlrpc.cgishow_bug.cgi?id=562085)**
## Description
The following subtyping is a valid according to the standard but not accepted by the TITAN:
type set r1 {
charstring f1,
charstring f3 optional
}
type r1 r1s ({f3:=omit})
proba.ttcn:10.14-24: error: Field `f1' is missing from set value
6.2.13.2:
When constraining record and set types, templates of the expanded list defined using the value list notation shall be valid (i.e. complete) templates, while templates of the expanded list defined using the field assignment notation may be partial (i.e. incomplete). In the latter case, the fields that are not explicitly present shall be considered as containing AnyValue for mandatory fields and AnyValueOrNone for optional fields.
Version: 6.6.1Adam KnappAdam Knapp2022-05-04https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/575RAW encoder: wrong value if FIELDORDER msb with PADDING2021-11-10T08:22:39ZGábor SzalaiRAW encoder: wrong value if FIELDORDER msb with PADDING## Summary
The RAW encoder produces wrong encoded value if the FIELDORDER is msb and padding is used.
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type record my_rec{
bitstring f1 length(6)
} w...## Summary
The RAW encoder produces wrong encoded value if the FIELDORDER is msb and padding is used.
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type record my_rec{
bitstring f1 length(6)
} with {
variant "FIELDORDER(msb)"
variant "PADDING(dword32)"
}
template my_rec t_expected:={f1:='111111'B}
testcase t_1() runs on CT{
var bitstring vl_encoded
var my_rec vl_pdu:={f1:='111111'B}
var integer vl_res
vl_encoded:=encvalue(vl_pdu)
log(vl_encoded)
}
control{
execute(t_1())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
'11000000000000000000000000000000'B
## What is the expected correct behavior?
'11111100000000000000000000000000'B
## Titan version
Up to 8.0.0
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/574RAW decoder error: DTE during handling of out of range enum values2021-11-10T08:22:37ZGábor SzalaiRAW decoder error: DTE during handling of out of range enum values## Summary
The RAW decoder of enumerated type can't handle large out of range values. If the decoded value is not fit to int, the decoder throws DTE instead of correct failure code
## Steps and/or TTCN-3 code to reproduce
```
module p...## Summary
The RAW decoder of enumerated type can't handle large out of range values. If the decoded value is not fit to int, the decoder throws DTE instead of correct failure code
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type component CT {};
type enumerated my_enum{ a(0), b(1)} with {variant "FIELDLENGTH(32)"}
type union my_union{
my_enum f1,
octetstring f2
}
template my_union t_expected:={f2:='FFFFFFFF'O}
testcase t_1() runs on CT{
var bitstring vl_encoded:='11111111111111111111111111111111'B
var my_union vl_pdu
var integer vl_res:=decvalue(vl_encoded,vl_pdu)
log(vl_res)
log(vl_pdu)
if(vl_res == 0 and match(vl_pdu,t_expected)){
setverdict(pass)
} else {
setverdict(fail)
}
}
control{
execute(t_1())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
Dynamic test case error: Invalid conversion of a large integer value
## What is the expected correct behavior?
pass
## Titan version
Up to 8.0.0
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/573Infinite recursion caused by multiple ASN.1 parameterized type instances2021-12-02T07:16:43ZBotond BaranyiInfinite recursion caused by multiple ASN.1 parameterized type instances## Summary
Multiple instances of the same ASN.1 parameterized type in a type hierarchy cause an infinite recursion during semantic analysis.
## ASN.1 code to reproduce
A
DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
Uint8 ::= INTEGER (0.....## Summary
Multiple instances of the same ASN.1 parameterized type in a type hierarchy cause an infinite recursion during semantic analysis.
## ASN.1 code to reproduce
A
DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
Uint8 ::= INTEGER (0..255)
ScmsPdu ::= SEQUENCE {
version Uint8 (2),
content CHOICE {
aca-ra AcaRaInterfacePdu,
int INTEGER,
...
}
}
ScmsPdu-Scoped {Pdu} ::= ScmsPdu (WITH COMPONENTS {
...,
content (CONSTRAINED BY {
Pdu
})
})
AcaRaInterfacePdu ::= CHOICE {
a Again,
...
}
Again ::= ScmsPdu-Scoped {
INTEGER
}
END
## What is the current bug behavior?
The compiler crashes due to an infinite recursion.
## What is the expected correct behavior?
Successful semantic analysis.
## Relevant logs and/or screenshots
-
## Possible fixes
-
## Titan version
8.0.0
## Platform details (OS type and version)
Any.Botond BaranyiBotond Baranyi2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/572Titan can not handle timers set to more than 25 days2021-11-10T08:22:42ZLenard NagyTitan can not handle timers set to more than 25 days## Summary
Titan can not handle timers set to more than 25 days
## Steps and/or TTCN-3 code to reproduce
Set any timer to more than 2147483 seconds
## What is the current bug behavior?
The too long timer will be set to 2147483 secon...## Summary
Titan can not handle timers set to more than 25 days
## Steps and/or TTCN-3 code to reproduce
Set any timer to more than 2147483 seconds
## What is the current bug behavior?
The too long timer will be set to 2147483 seconds and a Warning is displayed
## What is the expected correct behavior?
The TTCN-3 standard does not specify maximum timeout limit, so any positive float value should be accepted and handled
## Relevant logs and/or screenshots
Warning: The time needed for the first timer expiry is 2.14748e+07 seconds. The operating system does not support such long waiting at once. The maximum time of blocking was set to 2147483 seconds (ca. 24 days).
## Possible fixes
In `void TTCN_Snapshot::take_new(boolean block_execution)`
~~~c
} else {
// issue a warning: the user probably does not want such
// long waiting
TTCN_warning("The time needed for the first timer "
"expiry is %g seconds. The operating system does "
"not support such long waiting at once. The "
"maximum time of blocking was set to %d seconds "
"(ca. %d days).", block_time, MAX_BLOCK_TIME,
MAX_BLOCK_TIME / 86400);
// also modify the the timeout value to get out
// immediately from the while() loop below
timeout = current_time + (double)MAX_BLOCK_TIME;
pollTimeout = MAX_BLOCK_TIME * 1000;
handleTimer = TRUE;
}
~~~
## Titan version
8.0.0
## Platform details (OS type and version)
All
/cc @aknappqwt2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/560CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code2021-11-10T08:22:29ZLenard NagyCROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ codeOriginal Bugzilla bug written by Pau Espin Pedrol:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574469
## Summary
CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code
## Steps and/or TTCN-3 code to reproduce
Following T...Original Bugzilla bug written by Pau Espin Pedrol:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574469
## Summary
CROSSTAG(OTHERWISE) one 1 field union generates incorrect C++ code
## Steps and/or TTCN-3 code to reproduce
Following TTCN3 code compiles fine, but generates incorrect C++ code:
~~~
type union PCUIF_ContainerMsgUnion {
octetstring other
} with { variant "" };
type record PCUIF_container {
uint8_t msg_type,
uint8_t spare,
uint16_t len,
PCUIF_ContainerMsgUnion u
} with {
variant (len) "LENGTHTO(u)"
variant (u) "CROSSTAG(
other, OTHERWISE)"
};
~~~
Then when C++ code is compiled:
~~~
g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -I/usr/ttcn3/include -fPIC -o RSL_Emulation.o RSL_Emulation.cc
PCUIF_Types.cc: In member function ‘int PCUIF__Types::PCUIF__container::RAW_decode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int, raw_order_t, boolean, int, boolean, const RAW_Force_Omit*)’:
PCUIF_Types.cc:31342:3: error: ‘else’ without a previous ‘if’
31342 | else selected_field = 0;
| ^~~~
~~~
So it seems the TTCN3->C++ compiler is missing checking specific cases where the union (or the CROSSTAG) has only 1 OTHERWISE option.
Rationale for TTCN3 code shown above:
I wrote that TTCN3 code since I'm implementing the container layer without having yet any specific message in top of it specified, which will come later. Hence I wanted to have some octetstring on top to send random data to test only up to the container layer, while leaving the TTCN3 records prepared to add new container payload data in the future.
## Titan version
6.6.1
/cc @aknappqwtAdam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/558RAW encdec: overindexing of the buffer2021-11-10T08:22:25ZGábor SzalaiRAW encdec: overindexing of the buffer## Summary
The buffer can be overindexed in the RAW decoder during the decoding of the last field.
## Steps and/or TTCN-3 code to reproduce
Use the test case of the Issue #557
C++ Run the test with valgrind
Java Just run the test cas...## Summary
The buffer can be overindexed in the RAW decoder during the decoding of the last field.
## Steps and/or TTCN-3 code to reproduce
Use the test case of the Issue #557
C++ Run the test with valgrind
Java Just run the test case
## What is the current bug behavior?
C++, Valgrind
```
==13478== Invalid read of size 1
==13478== at 0x17EFE2: TTCN_Buffer::get_byte_align(unsigned long, raw_order_t, raw_order_t, unsigned long) (in /home/ethgasz/proba/a/proba)
==13478== by 0x17F6FD: TTCN_Buffer::get_b(unsigned long, unsigned char*, RAW_coding_par const&, raw_order_t) (in /home/ethgasz/proba/a/proba)
==13478== by 0x1881C2: HEXSTRING::RAW_decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, raw_order_t, bool, int, bool, RAW_Force_Omit const*) (in /home/ethgasz/proba/a/proba)
==13478== by 0x13F2E4: proba::R4::RAW_decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, raw_order_t, bool, int, bool, RAW_Force_Omit const*) (in /home/ethgasz/proba/a/proba)
==13478== by 0x13E9E9: proba::R4::decode(TTCN_Typedescriptor_t const&, TTCN_Buffer&, int, ...) (in /home/ethgasz/proba/a/proba)
==13478== by 0x1531C5: proba::R4_decoder(OCTETSTRING&, proba::R4&, UNIVERSAL_CHARSTRING const&) (in /home/ethgasz/proba/a/proba)
```
Java:
Index overflowGábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/557RAW enc/dec error, hexstring, FILEDORDER(msb), HEXORDER(high), field starts o...2021-11-10T08:22:23ZGábor SzalaiRAW enc/dec error, hexstring, FILEDORDER(msb), HEXORDER(high), field starts on half octet## Summary
The encoding of the hexstring is faulty if:
- FILEDORDER(msb)
- HEXORDER(high)
- The field starts on the half octet
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type record R4{
bitstring f1 length(4),
h...## Summary
The encoding of the hexstring is faulty if:
- FILEDORDER(msb)
- HEXORDER(high)
- The field starts on the half octet
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type record R4{
bitstring f1 length(4),
hexstring f2
} with {
variant (f2) "HEXORDER(high)"
variant "FIELDORDER(msb)"
}
type component CT{}
template bitstring t_expected_encoded:=oct2bit('F123456789'O)
template R4 t_expected_decoded:={'1111'B, '123456789'H }
testcase TC2() runs on CT {
var R4 vl_pdu4:={'1111'B, '123456789'H }
var bitstring vl_encoded:=encvalue(vl_pdu4)
log(vl_pdu4, " encoded as ",bit2oct(vl_encoded), " expected as ", bit2oct(valueof(t_expected_encoded)))
if(match(vl_encoded,t_expected_encoded)){
setverdict(pass)
} else {
setverdict(fail, "wrong encoded value")
}
vl_encoded:=valueof(t_expected_encoded)
var integer vl_res:=decvalue(vl_encoded,vl_pdu4)
log("decode result: ", vl_res)
if(vl_res == 0) {
setverdict(pass)
log(bit2oct(valueof(t_expected_encoded)), " decoded as ",vl_pdu4, " expected as ", t_expected_decoded)
if(match(vl_pdu4,t_expected_decoded)){
setverdict(pass)
} else {
setverdict(fail, "wrong decoded value")
}
} else {
setverdict(fail, "Decoding failed")
}
}
control {
execute(TC2())
}
} with {encode "RAW"}
```
## What is the current bug behavior?
```
15:05:12.936648 proba.ttcn:69 Component type proba.CT was initialized.
15:05:12.937090 proba.ttcn:73 { f1 := '1111'B, f2 := '123456789'H }encoded as 'F315274968'O expected as 'F123456789'O
15:05:12.937457 proba.ttcn:77 setverdict(fail): none -> fail reason: "wrong encoded value", new component reason: "wrong encoded value"
15:05:12.937788 proba.ttcn:83 decode result: 0
15:05:12.938259 proba.ttcn:87 'F123456789'Odecoded as { f1 := '1111'B, f2 := '241638597'H } expected as { f1 := '1111'B, f2 := '123456789'H }
15:05:12.938626 proba.ttcn:91 setverdict(fail): fail -> fail reason: "wrong decoded value", component reason not changed
```
## What is the expected correct behavior?
```
15:08:15.666778 proba.ttcn:73 { f1 := '1111'B, f2 := '123456789'H } encoded as 'F123456789'O expected as 'F123456789'O
15:08:15.667254 proba.ttcn:75 setverdict(pass): none -> pass
15:08:15.667984 proba.ttcn:83 decode result: 0
15:08:15.668373 proba.ttcn:86 setverdict(pass): pass -> pass, component reason not changed
15:08:15.668687 proba.ttcn:87 'F123456789'O decoded as { f1 := '1111'B, f2 := '123456789'H } expected as { f1 := '1111'B, f2 := '123456789'H }
15:08:15.669039 proba.ttcn:89 setverdict(pass): pass -> pass, component reason not changed
```
## Titan version
Up to 8.0.0Gábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/556make clean can cause “Argument list too long” error2021-11-10T08:22:21ZAdam Knappmake clean can cause “Argument list too long” error## Summary
In the generated Makefile all files are cleaned in one command
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS) $(GENERATED_HEADERS) \
$(GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES) ...## Summary
In the generated Makefile all files are cleaned in one command
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS) $(GENERATED_HEADERS) \
$(GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES) compile $(DEPFILES) \
tags *.log
```
With a lot of files `Argument list too long` error is got.
## Possible fixes
Separate the clean command, e.g.
```make
clean:
-$(RM) $(EXECUTABLE) $(LIBRARY) $(OBJECTS)
-$(RM) $(GENERATED_HEADERS)
-$(RM) $ (GENERATED_SOURCES) $(PREPROCESSED_TTCN3_MODULES)
-$(RM) compile $(DEPFILES) tags *.log
```
## Titan version
8.0.0.
/cc @aknappqwtAdam KnappAdam Knapp2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/555RAW decoding error, hexstring, HEXORDER (high), FIELDORDER(msb)2021-11-10T08:22:18ZGábor SzalaiRAW decoding error, hexstring, HEXORDER (high), FIELDORDER(msb)## Summary
The RAW encoder fails to correctly decode the last digit of hexstring if
- the hexstring is odd number length and length > 2
- and variant "HEXORDER (high)"
- nad variant "FIELDORDER(msb)"
## Steps and/or TTCN-3 code to rep...## Summary
The RAW encoder fails to correctly decode the last digit of hexstring if
- the hexstring is odd number length and length > 2
- and variant "HEXORDER (high)"
- nad variant "FIELDORDER(msb)"
## Steps and/or TTCN-3 code to reproduce
```
module proba{
type record MyRec{
MCC mcc,
bitstring bs length(4)
} with {
variant "FIELDORDER(msb)"
}
type hexstring MCC
with {
variant "FIELDLENGTH (3)";
variant "FIELDORDER(msb)"
variant "HEXORDER (high)";
}
type component CT{}
template MyRec t_hex:={
mcc:='042'H,
bs:='0000'B
}
testcase TChex() runs on CT {
var bitstring bdata:='0000010000100000'B
var MyRec res
var integer i:=decvalue(bdata,res)
log(i)
if(i!=0){
setverdict(fail, "decvalue failed")
} else {
log(res)
if(match(res,t_hex)){
setverdict(pass)
} else {
setverdict(fail, "unmatched value")
}
}
}
control {
execute(TChex())
}
} with { encode "RAW" }
```
## What is the current bug behavior?
`{ mcc := '040'H, bs := '0000'B }`
## What is the expected correct behavior?
`{ mcc := '042'H, bs := '0000'B }`
## Titan version
up to 8.0.0Gábor SzalaiGábor Szalai2021-11-09https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/721Error when generating PER descriptor containing reference to a constant in an...2024-03-27T16:52:57ZBotond BaranyiError when generating PER descriptor containing reference to a constant in another module## Summary
ASN.1 type constraints can contain references to constants, which are generated into the C++ code if these constraints are relevant to PER. If the referenced constant is defined in another ASN.1 module, then the compiler cras...## Summary
ASN.1 type constraints can contain references to constants, which are generated into the C++ code if these constraints are relevant to PER. If the referenced constant is defined in another ASN.1 module, then the compiler crashes with a fatal error.
## Steps and/or TTCN-3 code to reproduce
Imported module:
`objid-val OBJECT IDENTIFIER ::= { itu-t(0) recommendation(0) a(1) b(3) }`
Importing module:
`CharStr ::= CHARACTER STRING ( WITH COMPONENTS { identification ( syntaxes: { abstract objid-val, transfer objid-val } ) } )`
## What is the current bug behavior?
Compiler crashes with a fatal error
## What is the expected correct behavior?
Successful code generation
## Relevant logs and/or screenshots
-
## Possible fixes
Implement Ref_defd::generate_code_const_ref()
## Titan version
10.0.0
## Platform details (OS type and version)
Ubuntu 22.04
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/720PER_ALIGNED is used incorrectly2024-03-19T07:23:14ZCsaba RádulyPER_ALIGNED is used incorrectly## Summary
PER_ALIGNED is used incorrectly in several places
## Steps and/or TTCN-3 code to reproduce
In several places, the expression `(p_options && PER_ALIGNED)` is used. Using logical `&&` with a constant operand is incorrect.
The...## Summary
PER_ALIGNED is used incorrectly in several places
## Steps and/or TTCN-3 code to reproduce
In several places, the expression `(p_options && PER_ALIGNED)` is used. Using logical `&&` with a constant operand is incorrect.
The value of `PER_ALIGNED` is `0x01`, so this expression is true if `p_options` is not zero.
Bitwise `&` was likely intended.
## What is the current bug behavior?
Aligned PER encoding will be used when canonical PER is requested.
## What is the expected correct behavior?
Aligned PER encoding not used when only canonical PER is requested.
## Relevant logs and/or screenshots
-
## Possible fixes
Change `(p_options && PER_ALIGNED)` to `(p_options & PER_ALIGNED)`
```
core/Bitstring.cc:1432
core/Bitstring.cc:1484
core/Charstring.cc:1980
core/Charstring.cc:2333
core/Octetstring.cc:1549
core/Octetstring.cc:1594
core/Universal_charstring.cc:3297
core/Universal_charstring.cc:3371
```
## Titan version
Commit 129c715f0
## Platform details (OS type and version)
Any
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/719PER: extension groups with one field2024-03-27T16:52:57ZBotond BaranyiPER: extension groups with one fieldThe current PER encoder for sequences/sets treats extension groups with one field as if they were single extensions.
Example:
```
Seq ::= SEQUENCE {
...,
f1 BIT STRING (SIZE (1..8)) OPTIONAL,
[[ f2 BIT STRING (SIZE (1..8)) OPTIONA...The current PER encoder for sequences/sets treats extension groups with one field as if they were single extensions.
Example:
```
Seq ::= SEQUENCE {
...,
f1 BIT STRING (SIZE (1..8)) OPTIONAL,
[[ f2 BIT STRING (SIZE (1..8)) OPTIONAL ]]
}
```
In this example f1 needs to be encoded as if it was a field in the sequence, while f2 needs to be encoded as if it was a sequence with one field (including the optional bit). Currently both f1 and f2 are encoded as if they were fields.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/718PER: remove trailing 0 bits from bitstrings2024-03-27T14:41:45ZBotond BaranyiPER: remove trailing 0 bits from bitstringsAccording to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is alw...According to the PER standard:
"Where there are no PER-visible constraints and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies the value
shall be encoded with no trailing 0 bits (note that this means that a value with no 1 bits is always encoded as an empty bit
string).
Where there is a PER-visible constraint and Rec. ITU-T X.680 | ISO/IEC 8824-1, 22.7, applies (i.e., the bitstring
type is defined with a "NamedBitList"), the value shall be encoded with trailing 0 bits added or removed as necessary to
ensure that the size of the transmitted value is the smallest size capable of carrying this value and satisfies the effective
size constraint."
The current version of the PER encoder does not remove trailing 0 bits in any situation.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/717Configurable lib folder for OpenSSL to handle OpenSSL32024-03-19T07:23:19ZAdam KnappConfigurable lib folder for OpenSSL to handle OpenSSL3Depending on the install configuration, OpenSSL3 might use `lib64` folder instead of `lib`. In our Makefiles, `lib` is used. The proposed solution is to introduce a new variable `OPENSSL_LIB_DIR` that can be overwritten in the `Makefile....Depending on the install configuration, OpenSSL3 might use `lib64` folder instead of `lib`. In our Makefiles, `lib` is used. The proposed solution is to introduce a new variable `OPENSSL_LIB_DIR` that can be overwritten in the `Makefile.personal` on demand.Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/716ttcn3_logformat different otput format during unmatched text string2024-02-26T13:05:06ZPau Espin Pedrolttcn3_logformat different otput format during unmatched text string## Summary
In "unmatched: First message in the queue does not match the template" log lines, ttcn3_logformat prints output formatted differently:
- As "}\\n,{" in the "got" section
- As "}, {" in the "exp" section.
## Steps and/or TTC...## Summary
In "unmatched: First message in the queue does not match the template" log lines, ttcn3_logformat prints output formatted differently:
- As "}\\n,{" in the "got" section
- As "}, {" in the "exp" section.
## Steps and/or TTCN-3 code to reproduce
Take a long log line printing a "unmatched: First message in the queue does not match the template" case (see log.merged attached). This is basically of the sort "\[...\] with \[...\] format. I run ttcn3_logformat on it. I split manually the text into "got" file, and the text into the "exp" case. I use "meld" difftool to figure out the difference between the received (got) and expected (exp) message. Lot of lines differ, because the text is formatted as "}\\n,{", while the text is formatted as "}, {".
Not sure if the difference is due to "got" vs "exp" sections, or because the "exp" has the AVPs inside a "superset".
## What is the current bug behavior?
Different whitespace formatting is printed by ttcn3_logformat when re-encoding the same line.
## What is the expected correct behavior?
The same format should be applied for whitespace everywhere to make diffing easy.
## Relevant logs and/or screenshots
See attached files:
[exp.txt](/uploads/541d59a1c52b72f365be9bbe7e36d662/exp.txt)
[got.txt](/uploads/89865ab1a2e426b93fb430f46922fe65/got.txt)
[log.merged](/uploads/73eb0a1635c1316c15e9c18a09f33274/log.merged)
[ttcn3_format_output.txt](/uploads/5460e9b274cce8f6a2dc76cbaa7ef18f/ttcn3_format_output.txt)
## Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
## Titan version
```plaintext
$ ttcn3_compiler -v
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Version: 9.0.0
Build date: Sep 22 2023 23:38:05
Compiled with: GCC 13.2.1
Using OpenSSL 3.2.1 30 Jan 2024
Commit id: 67573c4
Copyright (c) 2000-2023 Ericsson Telecom AB
```
## Platform details (OS type and version)
Linux.
/cc @aknappqwt @mmagyarihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/711Unchecked module's attributes should not be cached2024-01-11T17:28:27ZBotond BaranyiUnchecked module's attributes should not be cachedA module's extension attributes can be cached (i.e. stored after they are first calculated, so they don't have to be calculated every time they're requested) before the semantic analysis of these attributes changes them (i.e. deletes som...A module's extension attributes can be cached (i.e. stored after they are first calculated, so they don't have to be calculated every time they're requested) before the semantic analysis of these attributes changes them (i.e. deletes some of them).
Consider the following example:
A.ttcn:
```
module A {
import from B all;
type record of Rec RoRec
with { encode "JSON" }
}
```
B.ttcn:
```
module B {
import from A all;
type record Rec {
integer num,
charstring str
}
external function f_enc(in Rec x) return octetstring
with { extension "prototype(convert) encode(RAW)" };
}
with {
encode "RAW"
extension "version R3A"
}
```
The following steps take place, when semantic analysis reaches module B:
- the check for imported module A is intiated (before module B itself is checked),
- the check for type RoRec in module A is initiated,
- the check for type Rec in module B is initiated (because it is contained in type RoRec),
- while checking type Rec's encodings, the parent module's attributes are calculated and cached, before the module has checked them (this results in a vector of 2 attributes, one 'encode' and one 'extension'),
- the check for type RoRec and module A is finished,
- the check for module B is initiated,
- module B's attributes are checked, this results in the extension attribute being deallocated,
- external function f_enc is checked, which requests the parent module's attributes, which returns the previously cached attributes.
The result a fatal error, because the 2nd attribute in the cache has already been deallocated.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/710warning: ‘ext_bit’ may be used uninitialized in this function2024-01-23T13:59:30ZGábor Szalaiwarning: ‘ext_bit’ may be used uninitialized in this function## Summary
The PER encoder of the extended enumeration causes c++ warning like:
```
CAP_datatypes_CAPv4.cc: In member function ‘void CAP__datatypes__CAPv4::EventTypeBCSM::PER_encode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int) cons...## Summary
The PER encoder of the extended enumeration causes c++ warning like:
```
CAP_datatypes_CAPv4.cc: In member function ‘void CAP__datatypes__CAPv4::EventTypeBCSM::PER_encode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int) const’:
CAP_datatypes_CAPv4.cc:22640:18: warning: ‘ext_bit’ may be used uninitialized in this function [-Wmaybe-uninitialized]
22640 | p_buf.PER_put_bit(ext_bit);
| ~~~~~~~~~~~~~~~~~^~~~~~~~~
```
## Steps and/or TTCN-3 code to reproduce
Example ASN.1 enum:
```
EventTypeBCSM ::= ENUMERATED {
collectedInfo (2),
analyzedInformation (3),
routeSelectFailure (4),
oCalledPartyBusy (5),
oNoAnswer (6),
oAnswer (7),
oMidCall (8),
oDisconnect (9),
oAbandon (10),
termAttemptAuthorized (12),
tBusy (13),
tNoAnswer (14),
tAnswer (15),
tMidCall (16),
tDisconnect (17),
tAbandon (18),
oTermSeized (19),
callAccepted (27),
oChangeOfPosition (50),
tChangeOfPosition (51),
...,
oServiceChange (52),
tServiceChange (53)
}
```
## What is the current bug behavior?
```
CAP_datatypes_CAPv4.cc: In member function ‘void CAP__datatypes__CAPv4::EventTypeBCSM::PER_encode(const TTCN_Typedescriptor_t&, TTCN_Buffer&, int) const’:
CAP_datatypes_CAPv4.cc:22640:18: warning: ‘ext_bit’ may be used uninitialized in this function [-Wmaybe-uninitialized]
22640 | p_buf.PER_put_bit(ext_bit);
| ~~~~~~~~~~~~~~~~~^~~~~~~~~
```
In ext_bit is not initialized if the value is unbound. It doesn't cause run time problem, just compile time warning.
## What is the expected correct behavior?
no warning.
## Possible fixes
Initialize the ext_bit when declared.
## Titan version
10.0.0 & git head
/cc @aknappqwt @mmagyariGábor SzalaiGábor Szalaihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/709Isvalue function causes segmentation fault2023-12-15T12:29:14ZAdam KnappIsvalue function causes segmentation faultSee: https://www.eclipse.org/forums/index.php/t/1114083/See: https://www.eclipse.org/forums/index.php/t/1114083/Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/708Sizeof function causes fatal error2023-12-05T13:59:24ZAdam KnappSizeof function causes fatal error## Summary
In certain cases, when a function returns template and the sizeof function is used on the returning template causes FATAL_ERROR in the compiler stopping the code generation completely.
## Steps and/or TTCN-3 code to reproduc...## Summary
In certain cases, when a function returns template and the sizeof function is used on the returning template causes FATAL_ERROR in the compiler stopping the code generation completely.
## Steps and/or TTCN-3 code to reproduce
The following code reproduces the issue:
```
// lengthof and sizeof (with functions returning templates)
type record Rec {
integer a optional,
boolean b
}
type record of Rec Rec_of;
function f2() return template Rec_of {
var template Rec_of x;
x[0].a := 0;
x[0].b := ?;
x[1].a := omit;
x[1].b := false;
return x;
}
function f3() return template Rec {
var template Rec t_rec := { ?, true };
return t_rec;
}
template Rec_of RoIret_global := f2();
template Rec rec_global := f3();
testcase tc_predef_sizeof_lengthof_func_rtemp() runs on CT {
template Rec_of RoIret_local := f2();
var template Rec_of RoIret_local_var := f2();
var integer size := lengthof(RoIret_global);
if (size != 2) {
setverdict(fail, "#1: ", size);
}
size := lengthof(RoIret_local);
if (size != 2) {
setverdict(fail, "#2: ", size);
}
size := lengthof(RoIret_local_var);
if (size != 2) {
setverdict(fail, "#3: ", size);
}
size := sizeof(rec_global);
if (size != 2) {
setverdict(fail, "#4: ", size);
}
size := sizeof(RoIret_global);
if (size != 2) {
setverdict(fail, "#5: ", size);
}
size := sizeof(RoIret_local);
if (size != 2) {
setverdict(fail, "#6: ", size);
}
size := sizeof(RoIret_local_var);
if (size != 2) {
setverdict(fail, "#7: ", size);
}
setverdict(pass);
}
```
## What is the current bug behavior?
FATAL_ERROR happens
## What is the expected correct behavior?
Compile without error
## Titan version
Titan 9.0.0
/cc @aknappqwtBotond BaranyiBotond Baranyi