modules break js connector silently
tsijs opened this issue · comments
When using the rtiddsgen to generate an xml from an idl that uses modules, the javascript connector breaks silently.
Steps to reproduce:
Try to run the basic example with the types inside a module.
The topics do not get subscribed or published on.
@tsijs I can't reproduce that behaviour, can you send a reproducer?
I made the following changes to ShapeExample.xml
<!-- types -->
<types>
- <struct name="ShapeType" extensibility="extensible">
- <member name="color" stringMaxLength="128" type="string" key="true"/>
- <member name="x" type="long"/>
- <member name="y" type="long"/>
- <member name="shapesize" type="long"/>
- </struct>
- <enum name="ShapeFillKind" extensibility="extensible">
- <enumerator name="SOLID_FILL" value="0"/>
- <enumerator name="TRANSPARENT_FILL" value="1"/>
- <enumerator name="HORIZONTAL_HATCH_FILL" value="2"/>
- <enumerator name="VERTICAL_HATCH_FILL" value="3"/>
- </enum>
- <struct name="ShapeTypeExtended" baseType="ShapeType" extensibility="extensible">
- <member name="fillKind" type="nonBasic" nonBasicTypeName="ShapeFillKind"/>
- <member name="angle" type="float"/>
- </struct>
+ <module name="MyModule">
+ <struct name="ShapeType" extensibility="extensible">
+ <member name="color" stringMaxLength="128" type="string" key="true"/>
+ <member name="x" type="long"/>
+ <member name="y" type="long"/>
+ <member name="shapesize" type="long"/>
+ </struct>
+ <enum name="ShapeFillKind" extensibility="extensible">
+ <enumerator name="SOLID_FILL" value="0"/>
+ <enumerator name="TRANSPARENT_FILL" value="1"/>
+ <enumerator name="HORIZONTAL_HATCH_FILL" value="2"/>
+ <enumerator name="VERTICAL_HATCH_FILL" value="3"/>
+ </enum>
+ <struct name="ShapeTypeExtended" baseType="ShapeType" extensibility="extensible">
+ <member name="fillKind" type="nonBasic" nonBasicTypeName="ShapeFillKind"/>
+ <member name="angle" type="float"/>
+ </struct>
+ </module>
</types>
<!-- Domain Library -->
<domain_library name="MyDomainLibrary">
<domain name="MyDomain" domain_id="0">
- <register_type name="ShapeType" type_ref="ShapeType" />
+ <register_type name="ShapeType" type_ref="MyModule::ShapeType" />
<topic name="Square" register_type_ref="ShapeType"/>
<topic name="Circle" register_type_ref="ShapeType"/>
<topic name="Triangle" register_type_ref="ShapeType"/>
And then ran the simple example's reader.js and writer.js (without making any changes) and communication occurs.
@samuelraeburn, thank you for taking the time to look into this issue.
When I run the simple example with the attached xml (which is very comparable to your example) it crashes after receiving some values. We also witness this in our own environment. This does not happen when not making use of namespaces/modules.
xml
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<!--
(c) 2005-2015 Copyright, Real-Time Innovations. All rights reserved.
No duplications, whole or partial, manual or electronic, may be made
without express written permission. Any such copies, or revisions thereof,
must display this notice unaltered.
This code contains trade secrets of Real-Time Innovations, Inc.
-->
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/current/rti_dds_profiles.xsd">
<!-- Qos Library -->
<qos_library name="QosLibrary">
<qos_profile name="DefaultProfile" base_name="BuiltinQosLibExp::Generic.StrictReliable" is_default_qos="true">
<domain_participant_qos>
<participant_name>
<name>Connector Shape Example</name>
</participant_name>
</domain_participant_qos>
</qos_profile>
</qos_library>
<!-- types -->
<types>
<module name="TESTERDETEST">
<struct name="ShapeType" extensibility="extensible">
<member name="color" stringMaxLength="128" type="string" key="true"/>
<member name="x" type="long"/>
<member name="y" type="long"/>
<member name="shapesize" type="long"/>
</struct>
<enum name="ShapeFillKind" extensibility="extensible">
<enumerator name="SOLID_FILL" value="0"/>
<enumerator name="TRANSPARENT_FILL" value="1"/>
<enumerator name="HORIZONTAL_HATCH_FILL" value="2"/>
<enumerator name="VERTICAL_HATCH_FILL" value="3"/>
</enum>
<struct name="ShapeTypeExtended" baseType="ShapeType" extensibility="extensible">
<member name="fillKind" type="nonBasic" nonBasicTypeName="ShapeFillKind"/>
<member name="angle" type="float"/>
</struct>
</module>
</types>
<!-- Domain Library -->
<domain_library name="MyDomainLibrary">
<domain name="MyDomain" domain_id="0">
<register_type name="ShapeType" type_ref="TESTERDETEST::ShapeType"/>
<topic name="Square" register_type_ref="ShapeType"/>
<topic name="Circle" register_type_ref="ShapeType"/>
<topic name="Triangle" register_type_ref="ShapeType"/>
</domain>
</domain_library>
<!-- Participant library -->
<domain_participant_library name="MyParticipantLibrary">
<domain_participant name="MyPubParticipant" domain_ref="MyDomainLibrary::MyDomain">
<publisher name="MyPublisher">
<data_writer name="MySquareWriter" topic_ref="Square"/>
</publisher>
</domain_participant>
<!-- We use separate participants because we run the writer and the reader
on different applications, and wouldn't want to create the reader
in writer.py, or the writer in reader.py -->
<domain_participant name="MySubParticipant" domain_ref="MyDomainLibrary::MyDomain">
<subscriber name="MySubscriber">
<data_reader name="MySquareReader" topic_ref="Square"/>
<data_reader name="MyCircleReader" topic_ref="Circle"/>
<data_reader name="MyTriangleReader" topic_ref="Triangle"/>
</subscriber>
</domain_participant>
<!-- You can also define the reader and writer inside the same
connector instance if you plan to use both in the same application.
-->
<domain_participant name="MyParticipant" domain_ref="MyDomainLibrary::MyDomain">
<publisher name="MyPublisher">
<data_writer name="MySquareWriter" topic_ref="Square"/>
</publisher>
<subscriber name="MySubscriber">
<!-- Uncomment this if you don't want the Input to start receiving
data before you call Connector.get_input()
-->
<!--
<subscriber_qos>
<entity_factory>
<autoenable_created_entities>false</autoenable_created_entities>
</entity_factory>
</subscriber_qos>
-->
<data_reader name="MySquareReader" topic_ref="Square"/>
</subscriber>
</domain_participant>
<!-- The transform.py script reads Squares and writes Circles -->
<domain_participant name="TransformationParticipant" domain_ref="MyDomainLibrary::MyDomain">
<subscriber name="MySubscriber">
<data_reader name="MySquareReader" topic_ref="Square"/>
</subscriber>
<publisher name="MyPublisher">
<data_writer name="MyCircleWriter" topic_ref="Circle"/>
</publisher>
</domain_participant>
<domain_participant name="CircleSubParticipant" domain_ref="MyDomainLibrary::MyDomain">
<subscriber name="MySubscriber">
<data_reader name="MyCircleReader" topic_ref="Circle"/>
</subscriber>
</domain_participant>
</domain_participant_library>
</dds>
Stack trace from node after crash:
Waiting for publications...
Waiting for data...
Received x: 0, y: 0, shapesize: 30, color: BLUE
Received x: 1, y: 2, shapesize: 30, color: BLUE #
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x7fff0114d990
1: 0xb6f151 [node]
2: 0x1bf56f4 V8_Fatal(char const*, ...) [node]
3: 0xfc3f61 v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptr<v8::internal::BackingStore>) [node]
4: 0xd151c8 v8::ArrayBuffer::GetBackingStore() [node]
5: 0xab71b0 napi_get_typedarray_info [node]
6: 0x7f1b8540b3af [/home/tsijs/src/rticonnextdds-connector-js/node_modules/ffi-napi/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]
7: 0x7f1b8540bbc8 [/home/tsijs/src/rticonnextdds-connector-js/node_modules/ffi-napi/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]
8: 0x7f1b8540d7a1 [/home/tsijs/src/rticonnextdds-connector-js/node_modules/ffi-napi/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]
9: 0x7f1b8541401b Napi::details::CallbackData<void (*)(Napi::CallbackInfo const&), void>::Wrapper(napi_env__*, napi_callback_info__*) [/home/tsijs/src/rticonnextdds-connector-js/node_modules/ffi-napi/node_modules/ref-napi/prebuilds/linux-x64/node.napi.node]
10: 0xaadf9d [node]
11: 0xd4a18e [node]
12: 0xd4b5af v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
13: 0x15e7959 [node]
[1] 9883 trace trap node ./reader.js
I hope these attachments help in reproducing the issue.
What version of Node.JS are you using?
Oops, you got me there. I did the test above a little too quick without activating my fnm env. That was with node v16.13.0.
This means that the above report is not valid, but we still have the issue in our environment, which is on node 10.24.1. I will look into that and get back here if it is related to the above, but feel free to close this ticket for now.
Thank you for taking the time.
Sure, glad we could get to the bottom of it.
We are still adding support for Node v14 and v16. The crash you saw was this one: node-ffi-napi/ref-napi#54