titan.core issueshttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues2021-11-10T08:22:39Zhttps://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/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/702integer is not treated as integer: The union type LENGTHTO field must contain...2023-11-15T09:56:50ZGábor Szalaiinteger is not treated as integer: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields## Summary
the
type integer INT1
is not identified as integer
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type union my_attribute_length {
INT1 short_length,
LIN2_BO_LAST extended_length
}
type record my_a...## Summary
the
type integer INT1
is not identified as integer
## Steps and/or TTCN-3 code to reproduce
```
module proba {
type union my_attribute_length {
INT1 short_length,
LIN2_BO_LAST extended_length
}
type record my_attribute {
my_attribute_length attribute_length,
octetstring attribute_value
} with {
variant (attribute_length) "LENGTHTO(attribute_value)"
}
type integer INT1 (0..255) with { variant "FIELDLENGTH(8)" };
type integer LIN2_BO_LAST (0..65535) with { variant "FIELDLENGTH(16), COMP(nosign), BYTEORDER(last)" };
} with {
encode "RAW"
}
```
## What is the current bug behavior?
proba.ttcn:8.6-11.1: error: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields
proba.ttcn:8.6-11.1: error: The union type LENGTHTO field must contain only integer, bitstring or octetstring fields
## What is the expected correct behavior?
no error
## Relevant logs and/or screenshots
The
```
type union my_attribute_length {
integer short_length,
integer extended_length
} with {
variant (short_length) "FIELDLENGTH(8)"
variant (extended_length) "FIELDLENGTH(16), COMP(nosign), BYTEORDER(last)"
}
```
compiled correctly
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/701AtNotation issue causing problems in BER and OER decoding2023-11-15T09:56:55ZAdam KnappAtNotation issue causing problems in BER and OER decodingDear Support,
I got an issue while decoding a COER packet encoded by TITAN COER codec.
I attached the sample project to illustrate the issue. The error is:
hello_world.ttcn:211: Dynamic test case error: Unbound left operand of integer c...Dear Support,
I got an issue while decoding a COER packet encoded by TITAN COER codec.
I attached the sample project to illustrate the issue. The error is:
hello_world.ttcn:211: Dynamic test case error: Unbound left operand of integer comparison.
It is linked ASN.1 files provided by IEEE 1609.2, IEEE 1609.2.1 and ETSI 103 759.
Many thanks in advanced for your support,
Best Regards,
Yann Garcia
The issue originates from this forum topic: https://www.eclipse.org/forums/index.php/t/1112887/Adam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/700Compilation issue in getter/setter functions2023-11-15T09:57:00ZBotond BaranyiCompilation issue in getter/setter functionsThe 'is_in_getter_scope' and 'is_in_setter_scope' functions don't compile on Alpine Linux.
See https://www.eclipse.org/forums/index.php/t/1113087/The 'is_in_getter_scope' and 'is_in_setter_scope' functions don't compile on Alpine Linux.
See https://www.eclipse.org/forums/index.php/t/1113087/Botond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/699Uncompilable generated code2023-11-15T09:57:06ZGábor SzalaiUncompilable generated code## Summary
The TITAN generates uncompilable code from the ASN.1 file
## Steps and/or TTCN-3 code to reproduce
Try to compile the generated code
## What is the current bug behavior?
error: redeclaration of ‘size_t pos’
size_t pos = p...## Summary
The TITAN generates uncompilable code from the ASN.1 file
## Steps and/or TTCN-3 code to reproduce
Try to compile the generated code
## What is the current bug behavior?
error: redeclaration of ‘size_t pos’
size_t pos = p_buf.get_pos();
^~~
error: redeclaration of ‘OER_struct tmp_oer’
OER_struct tmp_oer;
^~~~~~~
## Titan version
Latest
/cc @aknappqwt @mmagyariAdam KnappAdam Knapphttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/697gcc 4.8 compatibility issue2023-05-16T10:53:28ZGábor Szalaigcc 4.8 compatibility issue## Summary
(C++) Communication.cc
In file included from /usr/include/c++/4.8/unordered_map:35:0,
from Fd_And_Timeout_User.hh:27,
from Communication.cc:47:
/usr/include/c++/4.8/bits/c++0x_warning.h...## Summary
(C++) Communication.cc
In file included from /usr/include/c++/4.8/unordered_map:35:0,
from Fd_And_Timeout_User.hh:27,
from Communication.cc:47:
/usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from Communication.cc:47:0:
Fd_And_Timeout_User.hh:125:10: error: 'unordered_map' in namespace 'std' does not name a type
static std::unordered_map<int,Data> items;
^
Fd_And_Timeout_User.hh: In static member function 'static boolean FdMap::findInItems(int)':
Fd_And_Timeout_User.hh:112:12: error: 'items' was not declared in this scope
return items.find(fd)!=items.end();
^
/cc @aknappqwt @mmagyariGábor SzalaiGábor Szalaihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/696Extension additions of a SEQUENCE/SET are not set to optional2023-09-06T12:59:16ZAdam KnappExtension additions of a SEQUENCE/SET are not set to optional## Summary
According to the ASN.1 standard, "All fields in extension additions of a SEQUENCE type or a SET type shall be transformed to optional fields". This behavior is missing currently.
Originates from this forum post: https://www....## Summary
According to the ASN.1 standard, "All fields in extension additions of a SEQUENCE type or a SET type shall be transformed to optional fields". This behavior is missing currently.
Originates from this forum post: https://www.eclipse.org/forums/index.php/t/1112865/
## Titan version
All
## Platform details (OS type and version)
All
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/694Template initialization error2023-11-15T09:57:11ZLenard NagyTemplate initialization error## Summary
Original Titan Forum article:
https://www.eclipse.org/forums/index.php/t/1112705/
## Steps and/or TTCN-3 code to reproduce
[proba.ttcn](/uploads/2ce1c6fbbf9f5d026872aab8755fdd7e/proba.ttcn)
## What is the current bug behav...## Summary
Original Titan Forum article:
https://www.eclipse.org/forums/index.php/t/1112705/
## Steps and/or TTCN-3 code to reproduce
[proba.ttcn](/uploads/2ce1c6fbbf9f5d026872aab8755fdd7e/proba.ttcn)
## What is the current bug behavior?
Compiler crash
## Titan version
8.3.0
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/692xsd2ttcn: include doesn't copy import statements2023-05-16T10:53:32ZBotond Baranyixsd2ttcn: include doesn't copy import statementsWhen generating code for an 'include' statement from an XSD, the xsd2ttcn tool doesn't copy 'import' statements from the included schema. This is needed, since the elements/types in the included schema may depend on other types from the ...When generating code for an 'include' statement from an XSD, the xsd2ttcn tool doesn't copy 'import' statements from the included schema. This is needed, since the elements/types in the included schema may depend on other types from the imported schema.
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/690ttcn3 connect() on port triggering kernel OOM killer on component2023-05-16T10:53:34ZPau Espin Pedrolttcn3 connect() on port triggering kernel OOM killer on component## Summary
At osmocom we have a set of testsuites in TTCN3 which tests several telecommunications nodes in this repository [1]. Most tetsuite are run nightly with a prepared containerized setup under docker available at [2].
The PGW_Te...## Summary
At osmocom we have a set of testsuites in TTCN3 which tests several telecommunications nodes in this repository [1]. Most tetsuite are run nightly with a prepared containerized setup under docker available at [2].
The PGW_Tests setup (docker-playground.git/ttcn3-pgw-test/) starts a open5gs core network (specifically UPF and SMF) and tests creating 256 GTPv2 concurrent sessions against it (TC_createSession_ping4_256), launching 256 ping commands on one tun dev per conn. TTCN3 emulates OCS and PFC (Gx, Gy interface) as well as SGW (GTP). The most relevant code can be found at [3].
[1] https://gitea.osmocom.org/ttcn3/osmo-ttcn3-hacks
[2] https://gitea.osmocom.org/osmocom/docker-playground
[3] https://gitea.osmocom.org/ttcn3/osmo-ttcn3-hacks/src/branch/master/pgw/PGW_Tests.ttcn
In TTCN3, we have 1 component per GTP session, each in turn has ports connected to a Gx DIAMETER Gx and Gy DIAMETER components through component ports.
## Steps and/or TTCN-3 code to reproduce
Today, the PGW_Tests testsuite started to fail within a specific test: TC_createSession_ping4_256
Looking at the logs it seems the first 3-4 GTP sessions (ttcn3 components) are created fine and everything works fine, but at around the 4th-5th one it fails due to one component detecting a peer component closed the unix socket uses to intercommunicate with it (I also attah full merged log of all components during the failing test run[PGW_Tests.TC_createSession_ping4_256.pcap.gz](/uploads/97a31b296bf98c17556bf9118c0b09a1/PGW_Tests.TC_createSession_ping4_256.pcap.gz)[PGW_Tests.TC_createSession_ping4_256.merged.gz](/uploads/021bae01b9158ba54a7929c86110f144/PGW_Tests.TC_createSession_ping4_256.merged.gz)):
```
17:00:55.894883 22 - Connection of port DIAMETER to TC_createSession_ping4_256(4):DIAMETER_CLIENT was closed unexpectedly by the peer.
17:00:55.894983 19 PGW_Tests.ttcn:85 Connection of port DIAMETER_PROC to TC_createSession_ping4_256(4):DIAMETER_PROC was closed unexpectedly by the peer.
17:00:55.895109 16 PGW_Tests.ttcn:85 Connection of port DIAMETER_PROC to TC_createSession_ping4_256(4):DIAMETER_PROC was closed unexpectedly by the peer.
17:00:55.895114 13 PGW_Tests.ttcn:85 Connection of port DIAMETER_PROC to TC_createSession_ping4_256(4):DIAMETER_PROC was closed unexpectedly by the peer.
17:00:55.895215 10 PGW_Tests.ttcn:85 Connection of port DIAMETER_PROC to TC_createSession_ping4_256(4):DIAMETER_PROC was closed unexpectedly by the peer.
17:00:55.895219 7 PGW_Tests.ttcn:85 Connection of port DIAMETER_PROC to TC_createSession_ping4_256(4):DIAMETER_PROC was closed unexpectedly by the peer.
17:00:55.895260 22 - Port DIAMETER was disconnected from TC_createSession_ping4_256(4):DIAMETER_CLIENT.
17:00:55.895350 19 PGW_Tests.ttcn:85 Port DIAMETER_PROC was disconnected from TC_createSession_ping4_256(4):DIAMETER_PROC.
17:00:55.895386 mtc PGW_Tests.ttcn:275 Connection of port Gx_PROC to TC_createSession_ping4_256(4):DIAMETER_PROC was closed unexpectedly by the peer.
17:00:55.895423 16 PGW_Tests.ttcn:85 Port DIAMETER_PROC was disconnected from TC_createSession_ping4_256(4):DIAMETER_PROC.
17:00:55.895427 13 PGW_Tests.ttcn:85 Port DIAMETER_PROC was disconnected from TC_createSession_ping4_256(4):DIAMETER_PROC.
17:00:55.895509 10 PGW_Tests.ttcn:85 Port DIAMETER_PROC was disconnected from TC_createSession_ping4_256(4):DIAMETER_PROC.
17:00:55.895511 7 PGW_Tests.ttcn:85 Port DIAMETER_PROC was disconnected from TC_createSession_ping4_256(4):DIAMETER_PROC.
17:00:55.895743 mtc PGW_Tests.ttcn:275 Port Gx_PROC was disconnected from TC_createSession_ping4_256(4):DIAMETER_PROC.
17:00:55.896229 19 PGW_Tests.ttcn:85 Connection of port DIAMETER to TC_createSession_ping4_256(4):DIAMETER_CLIENT was reset by the peer.
17:00:55.896294 16 PGW_Tests.ttcn:85 Connection of port DIAMETER to TC_createSession_ping4_256(4):DIAMETER_CLIENT was closed unexpectedly by the peer.
17:00:55.896298 13 PGW_Tests.ttcn:85 Connection of port DIAMETER to TC_createSession_ping4_256(4):DIAMETER_CLIENT was closed unexpectedly by the peer.
17:00:55.896378 10 PGW_Tests.ttcn:85 Connection of port DIAMETER to TC_createSession_ping4_256(4):DIAMETER_CLIENT was closed unexpectedly by the peer.
17:00:55.896509 19 PGW_Tests.ttcn:85 Warning: The last outgoing messages on port DIAMETER may be lost.
17:00:55.896530 7 PGW_Tests.ttcn:85 Connection of port DIAMETER to TC_createSession_ping4_256(4):DIAMETER_CLIENT was closed unexpectedly by the peer.
17:00:55.896582 16 PGW_Tests.ttcn:85 Port DIAMETER was disconnected from TC_createSession_ping4_256(4):DIAMETER_CLIENT.
17:00:55.896586 13 PGW_Tests.ttcn:85 Port DIAMETER was disconnected from TC_createSession_ping4_256(4):DIAMETER_CLIENT.
17:00:55.896601 mtc PGW_Tests.ttcn:275 Connection of port Gx_UNIT to TC_createSession_ping4_256(4):DIAMETER_UNIT was closed unexpectedly by the peer.
17:00:55.896640 10 PGW_Tests.ttcn:85 Port DIAMETER was disconnected from TC_createSession_ping4_256(4):DIAMETER_CLIENT.
17:00:55.896762 7 PGW_Tests.ttcn:85 Port DIAMETER was disconnected from TC_createSession_ping4_256(4):DIAMETER_CLIENT.
17:00:55.896827 19 PGW_Tests.ttcn:85 Port DIAMETER was disconnected from TC_createSession_ping4_256(4):DIAMETER_CLIENT.
17:00:55.896851 mtc PGW_Tests.ttcn:275 Port Gx_UNIT was disconnected from TC_createSession_ping4_256(4):DIAMETER_UNIT.
17:00:55.897238 mtc PGW_Tests.ttcn:275 Dynamic test case error: Error message was received from MC: Establishment of port connection 4:DIAMETER_PROC - 22:DIAMETER_PROC failed because test component 4 has terminated during connection setup.
```
So looking at the TTCN3 logs (attached), I can compare the previous 3-4 created sessions with the last failing one, and it seems the "closed unexpectedly" happens while the port of the component is in the process of being connected() to the remote port (not yet completed).
When those errors show up, I get following output in "dmesg":
```
[28567.554950] __vm_enough_memory: pid: 233484, comm: PGW_Tests, no enough memory for the allocation
[28567.555002] __vm_enough_memory: pid: 233484, comm: PGW_Tests, no enough memory for the allocation
[28567.555066] __vm_enough_memory: pid: 233484, comm: PGW_Tests, no enough memory for the allocation
```
That's due to sysctl vm.overcommit_memory being 0 in my system (https://www.kernel.org/doc/html/latest/mm/overcommit-accounting.html). Disabling it (sysctl -w vm.overcommit_memory=1) makes it trigger the OOM killer every time I run the test, which kills the "PGW_Tests" binary containing the compiled TTCN3.
So I then run the "ttcn3_start" binary under "strace -ff -o /data/strace.log" to find out more. I get lots of strace.log, one per component (process). I grep for "unexpectedly" to find out the failing component, and look around to find out what's going on. According to the code, this happens because the unix socket recv() is returning 0. strace confirms that:
```
set_robust_list(0x7f9141acdee0, 24) = 0
close(3) = 0
epoll_create(16) = 3
close(4) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 4, 0x7ffc6c88dd5c) = -1 EBADF (Bad file descriptor)
fcntl(4, F_GETFD) = -1 EBADF (Bad file descriptor)
close(6) = 0
openat(AT_FDCWD, "PGW_Tests-TC_createSession_ping4_256-7b8d6c76ffd5-22.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 4
lseek(4, 0, SEEK_END) = 0
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(4, "17:00:54.715547 - Warning: A plu"..., 110) = 110
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.715905 - TTCN-3 Paralle"..., 235) = 235
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.716072 - TTCN Logger v2"..., 289) = 289
socket(AF_UNIX, SOCK_STREAM, 0) = 6
connect(6, {sa_family=AF_UNIX, sun_path="/tmp/ttcn3-mctr-33961"}, 110) = 0
fcntl(6, F_GETFD) = 0
fcntl(6, F_SETFD, FD_CLOEXEC) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN, {u32=6, u64=6}}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.716422 - Connected to M"..., 35) = 35
sendto(6, "\2\4\26", 3, 0, NULL, 0) = 3
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.716616 - Initializing v"..., 152) = 152
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.717908 - Port DIAMETER "..., 45) = 45
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.718042 - Port DIAMETER_"..., 50) = 50
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.718148 - Port DIAMETER_"..., 52) = 52
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.718230 - Component type"..., 81) = 81
epoll_wait(3, [{EPOLLIN, {u32=6, u64=6}}], 64, -1) = 1
recvfrom(6, "\200T\r\10DIAMETER\4\32TC_createSession_p"..., 1000, 0, NULL, NULL) = 86
socket(AF_UNIX, SOCK_STREAM, 0) = 7
connect(7, {sa_family=AF_UNIX, sun_path="/tmp/ttcn3-portconn-c554be55"}, 110) = 0 //<--- "/tmp/ttcn3-portconn-c554be55", fd=7
fcntl(7, F_GETFD) = 0
fcntl(7, F_SETFD, FD_CLOEXEC) = 0
fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLIN, {u32=7, u64=7}}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.718682 - Port DIAMETER "..., 141) = 141
epoll_wait(3, [{EPOLLIN|EPOLLHUP, {u32=7, u64=7}}], 64, -1) = 1 //<----- POLLED FOR READ!
recvfrom(7, "", 1000, 0, NULL, NULL) = 0 //<-------- recv() returns 0!!!!!! peer closed!
sendto(6, "\33\20\10DIAMETER\4\17DIAMETER_CLIENT", 28, 0, NULL, 0) = 28
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.894883 - Connection of "..., 132) = 132
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.895260 - Port DIAMETER "..., 101) = 101
epoll_ctl(3, EPOLL_CTL_DEL, 7, 0x7ffc6c88ddec) = 0
close(7) = 0
epoll_wait(3, [{EPOLLIN, {u32=6, u64=6}}], 64, -1) = 1
recvfrom(6, "\1\26", 1000, 0, NULL, NULL) = 2
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.904796 - Kill was reque"..., 68) = 68
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.905412 - Terminating co"..., 77) = 77
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.906088 - Port DIAMETER "..., 45) = 45
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.906693 - Port DIAMETER_"..., 50) = 50
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.907299 - Port DIAMETER_"..., 52) = 52
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.907881 - Component type"..., 122) = 122
sendto(6, "\3\27\0\0", 4, 0, NULL, 0) = 4
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.908685 - Final verdict "..., 45) = 45
sendto(6, "&\1\0\206\237\370\346G\267\273\r0\32Final verdict of PT"..., 39, 0, NULL, 0) = 39
shutdown(6, SHUT_WR) = 0
recvfrom(6, "", 1024, 0, NULL, NULL) = 0
close(6) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 6, 0x7ffc6c88dafc) = -1 EBADF (Bad file descriptor)
fcntl(6, F_GETFD) = -1 EBADF (Bad file descriptor)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.958218 - Disconnected f"..., 40) = 40
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:55.958534 - TTCN-3 Paralle"..., 59) = 59
rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f913d896d60}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f913d896d60}, NULL, 8) = 0
close(4) = 0
munmap(0x7f9141aae000, 32880) = 0
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++
```
So, the peer component is closing its socket, why? probably because it's crashing and the kernel is closing resources. Since the unix socket path is know from the above ("/tmp/ttcn3-portconn-c554be55"), we can easily identify the peer over all the other strace logs. Here it is (I attach the full file too[strace.log.46.gz](/uploads/75378688f6b57a50c5d5c688c9e38150/strace.log.46.gz)):
```
// This shows it's the component running DIAMETER_Emulation.main():
write(4, "17:00:53.675978 DIAMETER_Emulati"..., 133) = 133
sendto(6, "\200e\1\0\206\237\370\346E\251\241\n-\200XCreated Expect[0]"..., 103, 0, NULL, 0) = 103
[...]
// unix socket to which the component exiting with "unexepctedly closed by peer" is connecting:
socket(AF_UNIX, SOCK_STREAM, 0) = 11
getpid() = 46
bind(11, {sa_family=AF_UNIX, sun_path="/tmp/ttcn3-portconn-c554be55"}, 110) = 0
listen(11, 0) = 0
fcntl(11, F_GETFD) = 0
fcntl(11, F_SETFD, FD_CLOEXEC) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 11, {EPOLLIN, {u32=11, u64=11}}) = 0
sendto(6, "9\f\17DIAMETER_CLIENT\26\10DIAMETER\2\34/t"..., 58, 0, NULL, 0) = 58
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.717919 DIAMETER_Emulati"..., 183) = 183
[...]
//peer connects to us:
epoll_wait(3, [{EPOLLIN, {u32=11, u64=11}}], 64, -1) = 1
accept(11, NULL, NULL) = 22
fcntl(22, F_GETFD) = 0
fcntl(22, F_SETFD, FD_CLOEXEC) = 0
fcntl(22, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(22, F_SETFL, O_RDWR|O_NONBLOCK) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 11, 0x7ffc6c88cb3c) = 0
getsockname(11, {sa_family=AF_UNIX, sun_path="/tmp/ttcn3-portconn-c554be55"}, [110->31]) = 0
unlink("/tmp/ttcn3-portconn-c554be55") = 0
close(11) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 22, {EPOLLIN, {u32=22, u64=22}}) = 0
sendto(6, "\33\r\17DIAMETER_CLIENT\26\10DIAMETER", 28, 0, NULL, 0) = 28
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.727273 DIAMETER_Emulati"..., 139) = 139
epoll_wait(3, [{EPOLLIN, {u32=6, u64=6}}], 64, -1) = 1
recvfrom(6, ":\f\rDIAMETER_PROC\26\32TC_createSessi"..., 1000, 0, NULL, NULL) = 59
socket(AF_UNIX, SOCK_STREAM, 0) = 11
getpid() = 46
bind(11, {sa_family=AF_UNIX, sun_path="/tmp/ttcn3-portconn-df4eb11c"}, 110) = 0 //<---- HERE ANOTHER SOCKET WITH DIFFERENT PATH IS CREATED
listen(11, 0) = 0
fcntl(11, F_GETFD) = 0
fcntl(11, F_SETFD, FD_CLOEXEC) = 0
mmap(NULL, 17179869184, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) //<----- HERE MEM ALLOC OF 16GB!!!!!!! IT FAILS!!!!
brk(0x563e6dfce000) = 0x563a6dfbc000
mmap(NULL, 17180004352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
futex(0x7f9141b5f1e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(4, "17:00:54.732595 - Fatal error. A"..., 51) = 51 //<----- FAILURE TO ALLOC TRIGGERS TC_Error, ABORTS PROGRAM
sendto(6, ",\1\0\206\237\370\346F\254\3333\6 Fatal error. Aborti"..., 45, 0, NULL, 0) = 45
rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f913d896d60}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f913d896d60}, NULL, 8) = 0
close(4) = 0
munmap(0x7f9141aae000, 32880) = 0
close(3) = 0
sendto(6, "\30\20\rDIAMETER_UNIT\1\7Gx_UNIT", 25, 0, NULL, 0) = 25
epoll_ctl(-1, EPOLL_CTL_DEL, 7, 0x7ffc6c88d6dc) = -1 EBADF (Bad file descriptor)
fcntl(7, F_GETFD) = 0x1 (flags FD_CLOEXEC)
write(2, "terminate called after throwing "..., 48) = 48
write(2, "TC_Error", 8) = 8
write(2, "'\n", 2) = 2
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
getpid() = 46
gettid() = 46
tgkill(46, 46, SIGABRT) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=46, si_uid=0} ---
```
So allegadely according to logs and strace output, this mem allocation of 16GB (interestingly happens to be the memory on my system) which crashes the program happens when in PORT::connect_listen_unix_stream(), AFTER set_close_on_exec() is called (see strace) and before anything else is logged, which potentially means during calls to any of PORT::add_connection(), TTCN_Communication::send_connect_listen_ack_unix_stream() or TTCN_Logger::log_port_misc().
## What is the current bug behavior?
A TTCN3 component crashes trying to allocate all the memory in my system and obviously fails to do so, crashing.
## What is the expected correct behavior?
The TTCN3 component should not be attempting that big allocation of memory.
## Relevant logs and/or screenshots
Attached as explained above.
## Possible fixes
Couldn't find a fix for this.
## Titan version
titan.core version: 8.3.0
## Platform details (OS type and version)
linux: Linux 6.1.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 14 Feb 2023 22:08:08 +0000 x86_64 GNU/Linux
/cc @aknappqwt @mmagyariGábor SzalaiGábor Szalaihttps://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues/689Type compatibility issue for union templates2023-05-16T10:53:36ZBotond BaranyiType compatibility issue for union templates## Summary
Conversion between two templates of two different union types, that are compatible with each other, fails at runtime (RT2 only).
This issue was originally posted on the Eclipse forums: https://www.eclipse.org/forums/index.php...## Summary
Conversion between two templates of two different union types, that are compatible with each other, fails at runtime (RT2 only).
This issue was originally posted on the Eclipse forums: https://www.eclipse.org/forums/index.php/t/1112510/
## Steps and/or TTCN-3 code to reproduce
See example in the forum post.
## What is the current bug behavior?
Dynamic test case error during conversion.
## What is the expected correct behavior?
Successful conversion.
## Relevant logs and/or screenshots
See forum post.
## Possible fixes
Update the union template conversion function generator.
## Titan version
8.3.0
## Platform details (OS type and version)
Any
/cc @aknappqwt @mmagyariBotond BaranyiBotond Baranyi