Hi, I am developing both server and client for an application using ACE and OpenSSL. I am using the latest version of ACE, and OpenSSL 1.1.0f.

This code runs in the server, initializing the SSL Context:

ACE_SSL_Context *context = ACE_SSL_Context::instance();
context->set_mode(ACE_SSL_Context::SSLv23_server);
context->certificate("server_cert.pem", SSL_FILETYPE_PEM);
context->private_key("server_key.pem", SSL_FILETYPE_PEM);
if (context->load_trusted_ca("trusted.pem", 0, false) == -1) {
	ACE_ERROR_RETURN((LM_ERROR, "%p\n", "load_trusted_ca"), -1);
}

context->set_verify_peer(1, 1, 0);

if (context->have_trusted_ca() <= 0) {
	ACE_ERROR_RETURN((LM_ERROR, "%p\n", "have_trusted_ca"), -1);
}

This code runs in the client, initializing the SSL Context (so far, server certificate is not authenticated yet):

ACE_SSL_Context *context = ACE_SSL_Context::instance();
context->set_mode(ACE_SSL_Context::SSLv23_client);
context->certificate("C:/adq/client_cert.pem", SSL_FILETYPE_PEM);
context->private_key("C:/adq/client_key.pem", SSL_FILETYPE_PEM);

Client authentication works, and if I change the client certificates the connection is refused. However, the client starts throwing SSL errors after the first connection. The error shown is: "ACE_SSL error code: 336462231 - error:140E0197:SSL routines:SSL_shutdown:shutdown while in init".

Client side, there is an ACE_SSL_SOCK_Stream member that is reused by creating a connection, and then closing it, then creating a connection again, etc. This is the only thing that I imagine could be causing the issue. However, if I remove the line "context->set_verify_peer(1, 1, 0);" from the server program, the client works properly. Is the SSL_SOCK_Stream not reusable when authentication is enabled?

Anyways, a mutual authentication example would be appreciated since ACE_SSL offers a wrapper for mutual authentication but most SSL examples are quite simple.

Let me know if there is any more info I should provide.

• tests/Thread_Pool_Reactor_SSL_Test
• TAO/orbsvcs/tests/Security/Null_Cipher
• TAO/orbsvcs/DevGuideExamples/Security/PolicyControllingApp

key error message:
SSL routines:tls_construct_client_hello:no ciphers available

CI builds:
http://www.dre.vanderbilt.edu/scoreboard/tao.html
OpenSSL 1.1 example: Win_VC15_Debug
OpenSSL 1.0 example: Win2012R2x64_VC10_Debug

@okellogg related to #567, SunCC's preprocessor is still showing an incompatibility with the current lexer.

Would it be possible to split out the annotation parameter syntax from the annotation token itself? I guess the downside to that is that the parser would need to be made aware of the "application of annotation" rule in all places where we want to support it (perhaps not all legal places for now).

This is the preprocessor output from Bug_3940_Regression:

#1 "test.idl"
module test {

@ unit ( "deg" )
@ range ( min = 0.0 , max = 360.0 )
typedef float angle_t ;

@ unit ( "degC" ) @ min ( - 60 ) @ max ( 100 ) typedef short temperature_t ;

struct structure {
@ key unsigned long key ;
angle_t degrees ;
temperature_t celsius ;
} ;

} ;

Even in systems where execl, execle and execlp are supported , the ACE_OS::execl, ACE_OS::execle and ACE_OS::execlp methods are not implemented (see here).

This is not documented anywhere (or I couldn't find the relative documentation), therefore this is really confusing...

ACE_TSS_Cleanup::insert uses its key argument as an index into the into the internal storage array. The array is defined as

ACE_TSS_Info ACE_TSS_TABLE[ACE_DEFAULT_THREAD_KEYS]

The key in this case on Windows comes from the return value of ::TlsAlloc, which the documentation states:

The value of the TLS index should be treated as an opaque value; do not assume that it is an index into a zero-based array.

I am seeing the return value of ::TlsAlloc as a value large that 1088 (values in the 200k, 300k range).

As this is occurring in the call to ACE::init, we get a stack overflow caused by infinite recursion when asserts are enabled, this is the bottom of the trace:

146a 006ff178 024ca342 AppName!__ace_assert+0x21
146b 006ff1e8 024cda29 AppName!ACE_TSS_Cleanup::insert+0xa2
146c 006ff220 024c5b60 AppName!ACE_OS::thr_keycreate+0x89
146d 006ff230 024b6025 AppName!ACE_Thread::keycreate+0x10
146e 006ff29c 024cecd1 AppName!ACE_Log_Msg::instance+0x95
146f 006ff2ac 024ca342 AppName!__ace_assert+0x21
1470 006ff31c 024cda29 AppName!ACE_TSS_Cleanup::insert+0xa2
1471 006ff354 024c5b60 AppName!ACE_OS::thr_keycreate+0x89
1472 006ff364 024b6025 AppName!ACE_Thread::keycreate+0x10
1473 006ff3d0 024cecd1 AppName!ACE_Log_Msg::instance+0x95
1474 006ff3e0 024ca342 AppName!__ace_assert+0x21
1475 006ff450 024cda29 AppName!ACE_TSS_Cleanup::insert+0xa2
1476 006ff488 024c5b60 AppName!ACE_OS::thr_keycreate+0x89
1477 006ff498 024b6025 AppName!ACE_Thread::keycreate+0x10
1478 006ff504 024cecd1 AppName!ACE_Log_Msg::instance+0x95
1479 006ff514 024ca342 AppName!__ace_assert+0x21
147a 006ff584 024cda29 AppName!ACE_TSS_Cleanup::insert+0xa2
147b 006ff5bc 024c5b60 AppName!ACE_OS::thr_keycreate+0x89
147c 006ff5cc 024b6025 AppName!ACE_Thread::keycreate+0x10
147d 006ff638 024cecd1 AppName!ACE_Log_Msg::instance+0x95
147e 006ff648 024ca342 AppName!__ace_assert+0x21
147f 006ff6b8 024cda29 AppName!ACE_TSS_Cleanup::insert+0xa2
1480 006ff6f0 024c5b60 AppName!ACE_OS::thr_keycreate+0x89
1481 006ff700 025147a4 AppName!ACE_Thread::keycreate+0x10
1482 006ff71c 0251515d AppName!ACE_Threading_Helper<ACE_Thread_Mutex>::ACE_Threading_Helper<ACE_Thread_Mutex>+0x34
1483 006ff754 02516159 AppName!ACE_Service_Config::ACE_Service_Config+0x6d
1484 006ff77c 02515f66 AppName!ACE_Singleton<ACE_Service_Config,ACE_Recursive_Thread_Mutex>::ACE_Singleton<ACE_Service_Config,ACE_Recursive_Thread_Mutex>+0x59
1485 006ff788 02515ca3 AppName!ACE_Unmanaged_Singleton<ACE_Service_Config,ACE_Recursive_Thread_Mutex>::ACE_Unmanaged_Singleton<ACE_Service_Config,ACE_Recursive_Thread_Mutex>+0x16
1486 006ff7dc 02515028 AppName!ACE_Unmanaged_Singleton<ACE_Service_Config,ACE_Recursive_Thread_Mutex>::instance+0x83
1487 006ff7e4 02515450 AppName!ACE_Service_Config::singleton+0x8
1488 006ff7f0 025145b8 AppName!ACE_Service_Config::current+0x10
1489 006ff7f8 024ceed2 AppName!ACE_Service_Config::static_svcs+0x8
148a 006ff824 024cf6eb AppName!ACE_Object_Manager_Preallocations::ACE_Object_Manager_Preallocations+0x72
148b 006ff910 024cf89e AppName!ACE_Object_Manager::init+0x70b
148c 006ff93c 024cf9e5 AppName!ACE_Object_Manager::ACE_Object_Manager+0x10e
148d 006ff978 024ac16e AppName!ACE_Object_Manager::instance+0x85
148e 006ff988 018400aa AppName!ACE::init+0x1e

Note that the above trace is from an older version of ACE (ace-6.0.3b!!), however looking at the source for the current master branch, the issue still appears to be present.

Seen on Windows 10 Enterprise, 64bit.

Thanks.

See PR #553 for the test case.

Version

6.5.0-1

Compiler name and version (including patch level)

Visual Studio 2017 (15.7.3)

Description

When trying to build ACE with Visual Studio 2017 (ACE_vs2017.sln) following projects can not be opened:

• Gateway_Peer
• Test_Output

The error log shows

...\ACE_wrappers\apps\Gateway\Peer\Gateway_Peer_vs2017.vcxproj : error  : Cannot load project with duplicated project items: svc.conf is included as 'CustomBuild' and as 'None' item types. 

...\ACE_wrappers\tests\Test_Output_vs2017.vcxproj : error  : Cannot load project with duplicated project items: run_test.pl is included as 'None' and as 'None' item types. 

If the project files are edited manually - Removing

  <ItemGroup>

    <None Include="svc.conf" />

  </ItemGroup>

and

  <ItemGroup>

    <None Include="run_test.pl" />

  </ItemGroup>

The solution builds without errors.

The same issue seems to apply to TAO_ACE_vs2017.sln

We should upgrade to AppVeyor vs2017 support but looks we have a perl issue. On the vs2017 image we don't get a normal perl (see https://www.appveyor.com/docs/build-environment/#perl), we probably get a Cygwin version which fails to work, MPC doesn't work

Build started
git clone -q --depth=15 https://github.com/DOCGroup/ACE_TAO.git C:\projects\ace-tao-lc76l
git fetch -q origin +refs/pull/391/merge:
git checkout -qf FETCH_HEAD
Running Install scripts
mkdir ext && cd ext
git clone --depth 1 git://github.com/DOCGroup/MPC.git
Cloning into 'MPC'...
cd ..
set MPC_ROOT=%CD%\ext\MPC
set ACE_ROOT=%CD%\ACE
set TAO_ROOT=%CD%\TAO
set PATH=%ACE_ROOT%\lib:%PATH%
$CONTENT='#include "ace/config-win32.h"'
$CONTENT > ACE\ace\config.h
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26228.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
call perl %CD%\ACE\bin\mwc.pl -type vs2017 %CD%\TAO\TAO_ACE.mwc
MPC_ROOT was set to C:\projects\ace-tao-lc76l\ext\MPC.
Generating 'vs2017' output using C:/projects/ace-tao-lc76l/TAO/TAO_ACE.mwc
ace_xtreactor.mpc: line 2:
ERROR: Unable to locate parent: ace_xt
TAO_ACE.mwc: line 22:
ERROR: Unable to process C:/projects/ace-tao-lc76l/ACE/ace/XtReactor/ace_xtreactor.mpc
ERROR: Unable to process: TAO_ACE.mwc
Command exited with code 1

Looks to be since we migrated to git

Dear DOCGroup team,

I am considering adding a parallel CMake based multi-platform build system to the existing ACE_TAO code base. Before I put forth such an effort, I want to make sure that you would consider incorporating it.

Hans

The TAO_IDL parser changes in #723 accidentally broke parsing valuetype members that have public|private before the type. This shows up as a failure in CIAO's IDL3_to_XMI but may break TAO valuetypes as well.

We have discussed the design for a fix, which we expect to have ready soon.

Looks some mpc/mwc file still have automake sections which we can remove

Would be nice when we would have sonarcloud integration as static code checking

ACE 6.5.0 build under arch linux with openssl 1.1.1.

Build pass but program croe dump in openssl.

#0  0x00007f53ac19b31e in __strcmp_sse2_unaligned () from /usr/lib/libc.so.6
#1  0x00007f53ad0c1399 in lh_insert () from libfixapi_x64.so
#2  0x00007f53ad0a011b in OBJ_NAME_add () from libfixapi_x64.so
#3  0x00007efe52fe5c73 in ?? () from /usr/lib/libssl.so.1.1
#4  0x00007efe53c994ff in __pthread_once_slow () from /usr/lib/libpthread.so.0
#5  0x00007efe52ec3d8a in CRYPTO_THREAD_run_once () from /usr/lib/libcrypto.so.1.1
#6  0x00007efe52fe5e8d in OPENSSL_init_ssl () from /usr/lib/libssl.so.1.1
#7  0x00007efe53050d8e in ACE_SSL_Context::ssl_library_init (this=<optimized out>) at /home/xinr/ACE_wrappers/ace/SSL/SSL_Context.cpp:166
#8  0x00007efe5305148e in ACE_SSL_Context::ACE_SSL_Context (this=0x1f08b88) at /home/xinr/ACE_wrappers/ace/SSL/SSL_Context.cpp:115
#9  0x00007efe5305224b in ACE_Singleton<ACE_SSL_Context, ACE_Thread_Mutex>::ACE_Singleton (this=0x1f08b80) at /home/xinr/ACE_wrappers/ace/Cleanup.inl:5
#10 ACE_Unmanaged_Singleton<ACE_SSL_Context, ACE_Thread_Mutex>::ACE_Unmanaged_Singleton (this=0x1f08b80) at /home/xinr/ACE_wrappers/ace/Singleton.inl:15
#11 ACE_Unmanaged_Singleton<ACE_SSL_Context, ACE_Thread_Mutex>::instance () at /home/xinr/ACE_wrappers/ace/Singleton.cpp:230

Through the github API it should be possible to also automatically upload the created packages to github, would be nice when the release script would do that for us

Remove the tao imr locator notify_child_death operation, not used anymore by our activator

Ace_Log_Msg_UNIX_Syslog::convert_log_priority method in Log_Msg_UNIX_Syslog.cpp assigns:
syslog_priority = LOG_DEBUG, instead of : syslog_priority = LOG_DEBUGGING, resulting in assigning a string instead of an int value.

Version

ACE-6.0.1
TAO-2.0.1

Host machine and operating system

Windows 7

Target machine and operating system (if different from host)

Windows 7

Compiler name and version (including patch level)

Visual Studio 14

The $ACE_ROOT/ace/config.h file

https://pastebin.com/jH2kAvuD

Contents of $ACE_ROOT/bin/MakeProjectCreator/config/default.features

Not found.
Used by MPC when you generate your own makefiles

AREA/CLASS/EXAMPLE AFFECTED:

HTIOP.dll:
HTIOP_Connection_Handler.cpp:
int TAO::HTIOP::Connection_Handler::open (void*)

The problem effects:

Execution failed.

Synopsis

Array index is out of bounds in attempt to copy wide string to buffer of wide char.

Description

Look at line 123.
Local variable 'remote_addr' contains htid and tries to copy htid to wide buffer 'client' by method 'addr_to_string'. Something happened wrong into its implementation and at the end of function 'open'
VS throws "Stack around the variable 'client' was corrupted."

Sample fix/ workaround

Note that second parameter of 'addr_to_string' is number of bytes (not characters).
But if you look into implementation this parameter forwarded to 'ACE_OS::strncpy' like number of characters.
Also we must consider htid_.length() returns number of character, so code below is not correct.
// int ACE::HTBP::Addr::addr_to_string (ACE_TCHAR buffer[], size_t size, int ipaddr_format) const
if (size < htid_.length()) { /.../ }
I propose the following code:
https://pastebin.com/k0hJUMv5

In TAO_GIOP_Message_State::parse_message_header_i we should do a hexdump of the received data when we can't validate our GIOP header. That would help to analyze why it failed to handle a received message.

From the documentation associated with the ACE_Condition::wait(const ACE_Time_Value *abstime) method (ace/Condtion_T.h):

int wait (const ACE_Time_Value *abstime);
Block on condition, or until absolute time-of-day has passed. If @A abstime == 0 use "blocking" semantics. Else, if @A abstime != 0 and the call times out before the condition is signaled wait() returns -1 and sets errno to ETIME.

If native condition variables are enabled for Windows (via ACE_HAS_WTHREADS_CONDITION_VARIABLE) the Windows call ::SleepConditionVariableCS(....) is used. If the wait times out, this function will set a Windows-specific error, ERROR_TIMEOUT and not ETIME.

Hi, I don't know if this is the place to post this but I have been using ACE for a server and client implementation for several months now, and an error just appeared and I just can't find what is causing it.
There is stack corruption happening inside "handle_input" in Acceptor class.

I made a stack overflow post about it:
https://stackoverflow.com/questions/46006033/ace-run-time-check-failure-2-stack-around-variable-timeout-was-corrupted

Thanks, and sorry for the bother

make install the latest release error

Sorry for deleting all the standard questions. It's pretty simple: the Android NDK deprecates GCC, and using it gives various deprecation warnings and later compilation errors due to a broken mix of deprecated GCC stuff and new Clang stuff. These issues are marked as wontfix upstream, and GCC will be completely removed form the next release.

This library only supports GCC on Android, so Clang support is needed for compatibility with newer NDKs.

See

With C++17 std::auto_ptr support has been removed, we should look whether we can replace this with std::unique_ptr or use again some macro magic to automatically determine which type to be used.

Version

6.5.2

Host machine and operating system

RHEL 7 (but doesn't matter)

Target machine and operating system (if different from host)

Compiler name and version (including patch level)

gcc

The $ACE_ROOT/ace/config.h file

#include "ace/config-linux.h"
#define ACE_HAS_EVENT_POLL
#define ACE_HAS_IPV6

The $ACE_ROOT/include/makeinclude/platform_macros.GNU file

exceptions=1
debug=1
optimize=0
ssl=1
address-sanitizer=1
LDFLAGS=-static-libasan
include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU

Contents of $ACE_ROOT/bin/MakeProjectCreator/config/default.features

ssl=1
qos=1

AREA/CLASS/EXAMPLE AFFECTED:

ACE_Data_Block-derived user class.

The problem effects:

Memory management with user-defined class derived from ACE_Data_Block.

Synopsis

There is no way to indicate that a user class derived from ACE_Data_Block should be "delete"ed when released. Only option is a specific ACE_Allocator or the default ACE_Allocator::instance().

Description

A user-derived class from ACE_Data_Block can be passed to a new ACE_Message_Block as its data block. However, there is no way to indicate to ACE_Message_Block that the class's operator delete should be used to delete the object when needed. The default selects ACE_Allocator::instance() which ends up doing a delete [] char* on the area. This triggers a AddressSanitizer diagnostic similar to:
==9594== ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new vs operator delete []) on 0x600e0000de60

Repeat by

I have an addition to Message_Block_Test.cpp to illustrate this.
User_Data *user_data_block = 0;
ACE_NEW_RETURN (user_data_block,
User_Data (),
-1);

// Create a new message block referring to the User_Data block and
// ensure it is released and freed correctly.
ACE_Message_Block *wrapper_mb = 0;
ACE_NEW_RETURN (wrapper_mb,
ACE_Message_Block (user_data_block),
-1);

wrapper_mb->release ();

Sample fix/ workaround

Current idea is to change the default data_block_allocator for ACE_Data_Block from 0 to ACE_Allocator::instance() and allow 0 mean to use normal operator delete.

Getting issue on 6.4.6 ACExTAO with gcc 5.x toolchain. can anyone tell how to solve this error.

On run_tests.pl I got memory errors.

1970-01-01 00:06:44.029@LM_DEBUG@(1499|1995526144) Starting Malloc_Test test at 1970-01-01 00:06:44.029913
1970-01-01 00:06:44.030@LM_DEBUG@(1499|1995526144) Deleting old log file log/Malloc_Test-child.log (if any)

1970-01-01 00:06:44.030@LM_ERROR@MMAP_Memory_Pool::init_acquire, EEXIST: Cannot allocate memory
1970-01-01 00:06:44.036@LM_ERROR@(1499|1995526144) init_acquire failed: Cannot allocate memory
1970-01-01 00:06:44.036@LM_ERROR@ACE_Malloc_T<ACE_MEM_POOL_2, ACE_LOCK, ACE_CB>::ACE_Malloc_T: Cannot allocate memory

This is a low prio issue related to the TAO HTML documentation:

The following HREFs are not resolved due to the changed directory layout of the ACE_TAO git repo with respect to the ACE_wrappers source distro.

TAO/TAO-INSTALL.html

../ACE-INSTALL.html#platforms
../docs/usage-bugzilla.html
../MPC/docs/USAGE
../ACE/ACE-INSTALL.html#vxworks
../ACE-INSTALL.html#android
../ACE/ACE-INSTALL.html#vxworks
../ACE/ACE-INSTALL.html#VxWorks/NT
../bin/MakeProjectCreator/config/acedefaults.mpb
../ACE/ACE-INSTALL.html#resource_requirements
../MPC/docs/README
../ACE/ACE-INSTALL.html#MPC

TAO/docs/exceptions.html

../../docs/exceptions.html

TAO/docs/libraries.html

../../MPC/docs/README

TAO/docs/minimumTAO.html

../../ACE-INSTALL.html
../../ACE-INSTALL.html#flags

TAO/docs/Security/SSLIOP-INSTALL.html

../../../ACE-INSTALL.html#sslinstall
../../../ACE-INSTALL.html

I am not sure how to proceed because if this is fixed for git, it will be broken for ACE_wrappers.

When using the ImR with a per client server activation can result in hanging clients. This seem to happen when multiple clients very fast try to invoke the same server which results in multiple starts of the same server name, not all clients get a location forward back from the locator but they just hang forever

I think we can cleanup ACE_EXPORT_NESTED_CLASSES and TAO_EXPORT_NESTED_CLASSES, need to check this

The ImR activator could invoke the locator spawn_pid method using AMI, else we have to wait until we get a response back from the locator. The locator already handles the spawn_pid using AMH so it can takes some time and as activator we don't care about the result

With OpenSuse or CentOS, installation is simple, because they are available in the via the Open Build Service.

sudo zypper ar http://download.opensuse.org/repositories/devel:/libraries:/ACE:/micro/openSUSE_Tumbleweed/devel:libraries:ACE:micro.repo

This also, means it's really simple to add in a Dockerfile.

@jwillemsen is it possible to add Ubuntu?

Sorry if this is the wrong place for a request... But it looks like you're the maintainer of both
https://build.opensuse.org/project/users/devel:libraries:ACE

Thanks!

Dear all,

I'm trying to make multicast working with ACE on macOS.
I created this simple example (https://gist.github.com/francesco-romano/5a1634aae430046b58757ea7920db16f) which generates to simple applications: a receiver and a sender. It has been implemented both with plain BSD sockets and with ACE (you can switch by properly defining ACE_SOCKETS. (I've also created a simple CMakeLists to compile the example, where you can switch the two implementations. Unfortunaltey there not exist any FindAce.cmake, so you have to manually update the include and library variables)

While BSD implementation works, if I switch to ACE, I get an errno=49, i.e. Can't assign requested address as soon as I try to send a message.
Instead, if at https://gist.github.com/francesco-romano/5a1634aae430046b58757ea7920db16f#file-acesender-c-L45 I explicitly set OPT_BINDADDR_NO it works.

My system is macOS 10.11.6 on a quite new macbook Pro (retina).
Can you explain where is the error in my implementation?

(of course the real program is more complex than this example, but I managed to replicate the issue here)

Thanks 😄

The travis-ci configuration doesn't test the FACE configuration

Version

ACE 6.5.1, problem also applies to 6.5.2

Host machine and operating system

Windows 10 64 bit

Note: problem is limited to applications that use the Microsoft C\C++ runtime library on the Windows platform.

Compiler name and version (including patch level)

Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 for x86

AREA/CLASS/EXAMPLE AFFECTED:

global_macros.h

The problem effects:

The debug build of the ACE library disables the memory tracking feature of the Microsoft C\C++ runtime library.

Synopsis

The ACE library uses the ACE_NO_HEAP_CHECK macro at a couple of places to disable/enable memory tracking for a local function, however this design fails for multi-threading applications.

Description

The ACE library provides a class and macro to disable temporarily the memory leak tracking feature of the debug build of the Microsoft C\C++ runtime:

#define ACE_NO_HEAP_CHECK ACE_No_Heap_Check ____no_heap;

class ACE_Export ACE_No_Heap_Check
{
public:
ACE_No_Heap_Check (void)
: old_state (_CrtSetDbgFlag (_CRTDBG_REPORT_FLAG))
{ _CrtSetDbgFlag (old_state & ~_CRTDBG_ALLOC_MEM_DF);}
~ACE_No_Heap_Check (void) { _CrtSetDbgFlag (old_state);}
private:
int old_state;
};

The intend of the macro is that it should be used when a function is entered, to suppress false leaks. At function exit the original tracking state is restored.

However the concept of this design is flawed:

1. As long as the ACE_Export ACE_No_Heap_Check instance exists in one thread, all other memory allocations in other threads are also excluded from the memory tracking. All leakage during that time period are not reported by the CRT debug report when the application is exited.

2. If another thread uses also the ACE_NO_HEAP_CHECK ACE_No_Heap_Check macro when the tracking is already disabled by another ACE_NO_HEAP_CHECK ACE_No_Heap_Check macro, the old_state variable that will be retrieved to restore is the "disabled" state. Depending on the timing which destructor is executed first, the memory tracking is disabled completely for the remaining lifetime of the app. For example:
   Thread 1: ACE_NO_HEAP_CHECK ACE_No_Heap_Check constructor -> disables memory tracking
   Thread 2: ACE_NO_HEAP_CHECK ACE_No_Heap_Check constructor -> disables memory tracking, (old_state = disabled)
   Thread 1: ACE_NO_HEAP_CHECK ACE_No_Heap_Check destructor -> enables memory tracking
   Thread 2: ACE_NO_HEAP_CHECK ACE_No_Heap_Check destructor -> disables memory tracking
   Thread 3: ACE_NO_HEAP_CHECK ACE_No_Heap_Check constructor -> disables memory tracking
   Thread 3: ACE_NO_HEAP_CHECK ACE_No_Heap_Check destructor -> disables memory tracking

Repeat by

1. Add a explicit memory leak somewhere in code that is executed by a worker thread.
2. Execute the application (debug build)
3. Close the application
   Expected result: the MS CRT gives a list of leaked memory blocks.
   Actual result: no leaks are reported.

Sample fix/ workaround

My recommendation is remove the ACE_NO_HEAP_CHECK ACE_No_Heap_Check macro and the class ACE_Export ACE_No_Heap_Check to solve this issue.
If there are memory leaks reported afterwards (created by global singletons, for example), it means that additional modifications are needed to remove those, currently hidden, leaks.

Note: the Microsoft C runtime also provides a special debug version of malloc_dbg (internally used by the memory tracking system) that accept a blockType parameter. Passing "IGNORE_BLOCK" means that the leaked memory will not be reported as leaked. This could be an alternative solution to suppress leak warnings, when it is difficult\impossible to modify the leaking implementation.

Look whether TAO_EXPORT_MACRO can be cleaned, at the moment TAO_IDL needs some changes to use the real export macro this possible can be done

We observed a thread race condition in leader follower. Looks the state of LF_CH_Event is read without any thread safety outside of leader/follower. Working on some changes to have thread safe accessors (using the leader/follower lock) for checking the state outside of leader/follower where within the leader/follower loop we can just work within the leader/follower lock

23:10:07 WARNING: ThreadSanitizer: data race (pid=82284)
23:10:07   Read of size 4 at 0x7d48000177e0 by thread T16 (mutexes: write M390361):
23:10:07     #0 TAO_LF_CH_Event::successful() const TAO/tao/LF_CH_Event.cpp:115 (+0x000003fcc37e)
23:10:07     #1 TAO_LF_Event::keep_waiting() TAO/tao/../tao/LF_Event.inl:31 (+0x000003f2c62c)
23:10:07     #2 TAO_IIOP_Connector::complete_connection(int, TAO_Transport_Descriptor_Interface&, TAO_IIOP_Connection_Handler**&, TAO_IIOP_Endpoint**, unsigned int, TAO::Profile_Transport_Resolver*, TAO_LF_Multi_Event*, ACE_Time_Value*) TAO/tao/IIOP_Connector.cpp:578 (+0x000003fab8c2)
23:10:07     #3 TAO_IIOP_Connector::make_connection(TAO::Profile_Transport_Resolver*, TAO_Transport_Descriptor_Interface&, ACE_Time_Value*) TAO/tao/IIOP_Connector.cpp:217 (+0x000003fa99c2)
23:10:07     #4 TAO_Connector::connect(TAO::Profile_Transport_Resolver*, TAO_Transport_Descriptor_Interface*, ACE_Time_Value*) TAO/tao/Transport_Connector.cpp:665 (+0x000003f7087b)
23:10:07     #5 TAO::Profile_Transport_Resolver::try_connect_i(TAO_Transport_Descriptor_Interface*, ACE_Time_Value*, bool) TAO/tao/Profile_Transport_Resolver.cpp:169 (+0x000003f50075)
23:10:07     #6 TAO::Profile_Transport_Resolver::try_connect(TAO_Transport_Descriptor_Interface*, ACE_Time_Value*) TAO/tao/Profile_Transport_Resolver.cpp:112 (+0x000003f4fad2)
23:10:07     #7 TAO_Default_Endpoint_Selector::select_endpoint(TAO::Profile_Transport_Resolver*, ACE_Time_Value*) TAO/tao/Invocation_Endpoint_Selectors.cpp:64 (+0x000003f24f35)
23:10:07     #8 TAO::Profile_Transport_Resolver::resolve(ACE_Time_Value*) TAO/tao/Profile_Transport_Resolver.cpp:83 (+0x000003f4f72f)
23:10:07     #9 TAO::Invocation_Adapter::invoke_remote_i(TAO_Stub*, TAO_Operation_Details&, TAO_Pseudo_Var_T<CORBA::Object>&, ACE_Time_Value*&, TAO::Invocation_Retry_State*) TAO/tao/Invocation_Adapter.cpp:249 (+0x000003f201d6)
23:10:07     #10 TAO::Invocation_Adapter::invoke_i(TAO_Stub*, TAO_Operation_Details&) TAO/tao/Invocation_Adapter.cpp:97 (+0x000003f1e876)
23:10:07     #11 TAO::Invocation_Adapter::invoke(TAO::Exception_Data*, unsigned long) TAO/tao/Invocation_Adapter.cpp:46 (+0x000003f1dfac)
23:10:07     #12 TAO::Remote_Object_Proxy_Broker::_is_a(CORBA::Object*, char const*) TAO/tao/Remote_Object_Proxy_Broker.cpp:37 (+0x000003e58c37)
23:10:07     #13 CORBA::Object::_is_a(char const*) TAO/tao/Object.cpp:226 (+0x000003df31cb)

23:10:07   Previous write of size 4 at 0x7d48000177e0 by thread T11 (mutexes: write M374184):
23:10:07     #0 TAO_LF_CH_Event::validate_state_change(int) TAO/tao/LF_CH_Event.cpp:85 (+0x000003fcc1b3)
23:10:07     #1 TAO_LF_CH_Event::state_changed_i(int) TAO/tao/LF_CH_Event.cpp:37 (+0x000003fcbbab)
23:10:07     #2 TAO_LF_Event::state_changed(int, TAO_Leader_Follower&) TAO/tao/LF_Event.cpp:30 (+0x000003f2f72b)
23:10:07     #3 TAO_IIOP_Connection_Handler::open(void*) TAO/tao/IIOP_Connection_Handler.cpp:361 (+0x000003fa5706)
23:10:07     #4 ACE_Concurrency_Strategy<TAO_IIOP_Connection_Handler>::activate_svc_handler(TAO_IIOP_Connection_Handler*, void*) ace/Strategies_T.cpp:195 (+0x000003f9c9b0)
23:10:07     #5 TAO_Connect_Concurrency_Strategy<TAO_IIOP_Connection_Handler>::activate_svc_handler(TAO_IIOP_Connection_Handler*, void*) TAO/tao/../tao/Connector_Impl.cpp:53 (+0x000003fb0850)
23:10:07     #6 ACE_Strategy_Connector<TAO_IIOP_Connection_Handler, ACE_SOCK_Connector>::activate_svc_handler(TAO_IIOP_Connection_Handler*) ace/Connector.cpp:976 (+0x000003fb28cf)
23:10:07     #7 ACE_Connector<TAO_IIOP_Connection_Handler, ACE_SOCK_Connector>::initialize_svc_handler(int, TAO_IIOP_Connection_Handler*) ace/Connector.cpp:641 (+0x000003fb139f)
23:10:07     #8 ACE_NonBlocking_Connect_Handler<TAO_IIOP_Connection_Handler>::handle_output(int) ace/Connector.cpp:198 (+0x000003fb4c7b)
23:10:07     #9 ACE_TP_Reactor::dispatch_socket_event(ACE_EH_Dispatch_Info&) ace/TP_Reactor.cpp:543 (+0x0000040ee97f)
23:10:07     #10 ACE_TP_Reactor::handle_socket_events(int&, ACE_TP_Token_Guard&) ace/TP_Reactor.cpp:413 (+0x0000040edcbd)
23:10:07     #11 ACE_TP_Reactor::dispatch_i(ACE_Time_Value*, ACE_TP_Token_Guard&) ace/TP_Reactor.cpp:242 (+0x0000040ed1b3)
23:10:07     #12 ACE_TP_Reactor::handle_events(ACE_Time_Value*) ace/TP_Reactor.cpp:171 (+0x0000040ececf)
23:10:07     #13 ACE_Reactor::handle_events(ACE_Time_Value*) ace/Reactor.inl:185 (+0x000003e2a6d0)
23:10:07     #14 TAO_ORB_Core::run(ACE_Time_Value*, int) TAO/tao/ORB_Core.cpp:2317 (+0x000003e1cd2c)
23:10:07     #15 CORBA::ORB::run(ACE_Time_Value*) TAO/tao/ORB.cpp:188 (+0x000003dfed97)
23:10:07     #16 CORBA::ORB::run() TAO/tao/ORB.cpp:174 (+0x000003dfed04)

In IDL_Test we have typedef.idl which does

{
  typedef sequence<double> Dubble, Dubbel, Toil, Trouble;
};

In typedefC.h we generate CommaList::Dubble class but there is no implementation in typedefC.cpp (same for Dubbel and Toil), only for Trouble there is an implementation

Version

ACE_wrappers-6.2.4
openssl-1.0.2p

Host machine and operating system

SUSE Linux Enterprise Server 11 SP3 (x86_64) - Kernel

Target machine and operating system (if different from host)

SUSE Linux Enterprise Server 11 SP3 (x86_64) - Kernel

Compiler name and version (including patch level)

gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)

The $ACE_ROOT/ace/config.h file

ln -s config-linux.h config.h

The $ACE_ROOT/include/makeinclude/platform_macros.GNU file

ln -s platform_linux.GNU platform_macros.GNU

Contents of $ACE_ROOT/bin/MakeProjectCreator/config/default.features

no changes

AREA/CLASS/EXAMPLE AFFECTED:

TAO/orbsvcs/orbsvcs/SSLIOP

Error - ../../../bin/tao_idl: "SSLIOP.idl", line 24: error in lookup of symbol: Security::AssociationOptions
Error - ../../../bin/tao_idl: "SSLIOP.idl", line 25: error in lookup of symbol: Security::AssociationOptions
Error - ../../../bin/tao_idl: "SSLIOP.idl", line 44: error in lookup of symbol: CORBA::Current
make[1]: *** [SSLIOPC.h] Error 4
make[1]: Leaving directory `/opt/3rd/trunk/3rd_src/ACE_wrappers-6.2.4-05831UTR/TAO/orbsvcs/orbsvcs'
make: *** [SSLIOP] Error 2

The problem effects:

libTAO_SSLIOP.so compile error

Description

execute make ssl=1 in $TAO_ROOT ,got the error
please help me.

Hello.

I found a NULL pointer dereference in ACE_TAO.

Please confirm.

Thanks.

Summary: NULL pointer dereference
OS: CentOS 7 64bit
PoC Download: Null_UTL_IdList__head.zip

Steps to reproduce:
1.Download the .POC files.
2.Compile the source code with ASan.
3.Execute the following command
: ./tao_idl $POC

ASAN:DEADLYSIGNAL
=================================================================
==31676==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f7d41147f06 bp 0x7ffe7db1e810 sp 0x7ffe7db1e810 T0)
==31676==The signal is caused by a READ memory access.
==31676==Hint: address points to the zero page.
    #0 0x7f7d41147f05 in UTL_IdList::head() util/utl_idlist.cpp:115
    #1 0x7f7d41145571 in UTL_Scope::lookup_by_name(UTL_IdList*, bool, bool) util/utl_scope.cpp:1224
    #2 0x7f7d410dd99b in tao_yyparse() fe/idl.ypp:2485
    #3 0x7f7d410ea579 in FE_yyparse() fe/fe_extern.cpp:95
    #4 0x560bc0ada63d in DRV_drive(char const*) /home/karas/OpenDDS/ACE_wrappers/TAO/TAO_IDL/tao_idl.cpp:233
    #5 0x560bc0adad07 in main /home/karas/OpenDDS/ACE_wrappers/TAO/TAO_IDL/tao_idl.cpp:400
    #6 0x7f7d400631c0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x211c0)
    #7 0x560bc0ad2709 in _start (/home/karas/OpenDDS/run/bin/tao_idl+0x6709)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV util/utl_idlist.cpp:115 in UTL_IdList::head()
==31676==ABORTING

==========
[Acknowledgement]
This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001, Innovation hub for high Performance Computing]

Version

ACE 6.5.3
TAO 2.5.3
OS
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.6 (stretch)
Release: 9.6
Codename: stretch

in file:///home/guoyanzhang/ACE_wrappers/TAO/docs/tutorials/Quoter/Event_Service/index.html
test way:
Testing

To test your changes you need to run four programs, first TAO's Naming Service:

$ $TAO_ROOT/orbsvcs/Naming_Service/tao_cosnaming -m 1

The CORBA Event Service

$ $TAO_ROOT/orbsvcs/CosEvent_Service/tao_cosevent

Now you can run your client:

$ client

and finally the server:

$ server AAAA MSFT RHAT < stock_list.txt
but on my pc show:
issue :
guoyanzhang@debian:~/ACE_wrappers/TAO$ $TAO_ROOT/orbsvcs/CosEvent_Service/tao_cosevent
(30985|140575618819904) EXCEPTION, /home/guoyanzhang/ACE_wrappers/TAO/orbsvcs/CosEvent_Service/tao_cosevent
system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'
OMG minor code (2), described as 'No usable profile in IOR.', completed = NO

the make_release.py should update the content of the debian/*lintian-overrides

Version

current master

Host machine and operating system

linux

The $ACE_ROOT/include/makeinclude/platform_macros.GNU file

platform_linux_common.GNU

AREA/CLASS/EXAMPLE AFFECTED:

building

The problem effects:

compilation failure

Synopsis

getconf error (when asking for Large File Support) will lead to an incomprehensible error message

Description

We had a strange error building ACE on OSX

c++ -fvisibility=hidden -fvisibility-inlines-hidden -Wnon-virtual-dtor -O3 -ggdb -pthread -fno-strict-aliasing -Wall -W -Wpointer-arith -pipe -DACE_LACKS_LINUX_NPTL Unknown -D_GNU_SOURCE   -I/Users/rich/Documents/Code/SIRF-Superbuild/Build/builds/ACE/build/source/ -D__ACE_INLINE__ -I.. -DACE_BUILD_DLL  -c -fPIC -o .shobj/ACE.o /Users/rich/Documents/Code/SIRF-SuperBuild/Build/builds/ACE/build/source/ace/ACE.cpp
clang: error: no such file or directory: 'Unknown'

It seems that this error was caused by using the wrong platform file (more detail at SyneRBI/SIRF-SuperBuild#186). However, looking at the code that causes this:

PLATFORM_LARGEFILE_CFLAGS := $(shell getconf LFS_CFLAGS 2> /dev/null || echo Unknown)
ifdef PLATFORM_LARGEFILE_CFLAGS
  # Large file support
  CPPFLAGS += $(PLATFORM_LARGEFILE_CFLAGS)
endif #largefile

it appears that if getconf fails for some reason, this error will appear. There's 2 possible solutions I guess:

• let make fail with an understandable error
• proceed assuming that nothing needs to be added to CPPFLAGS

This is maybe a corner case that is not worth your time of course, but I thought I'd file it.

https://www.appveyor.com/docs/build-environment/#pre-installed-software
https://www.appveyor.com/docs/windows-images-software/#visual-studio-2013

Version

ACE : 6.5.2

Host machine and operating system

Windows 7 64bit

Compiler name and version (including patch level)

VS2010

AREA/CLASS/EXAMPLE AFFECTED:

QtReactor

The problem effects & Synopsis & Description

I was developing a project ,which can recv data from udp and serial port, and draw data to GUI.
I use Reactor framework (Implement is QtReactor ) to handle udp events. Because on Windows,Reactor don't support serial port IO, I use Proactor to handle serial port IO.
Both goes well independtly (one framework one process).
when I combine these into a process, I got error.
code as follow:

QApplication a(argc,argv);
Mainwindow w;

ACE_Proactor::close_singleton();
ACE_WIN32_Proactor *impl = new ACE_WIN32_Proactor(0,1);
ACE_Proactor::instance(new ACE_WIN32_Proactor(impl,1),1);

ACE_QtReactor qtreactor(&a);
ACE_Reactor reactor;

reactor.register_handler(impl,impl->get_handle());
.....

register_handler return -1.
if I use ACE_Reactor::instance()->register_handler(impl,impl->get_handle()), it return correct.

I guess QtReactor don't support register_handler(impl,impl->get_handle()).

does it built already with these options ?

ACE_HAS_WCHAR
ACE_USES_WCHAR

for example the rpms in this site, for Centos 7:
http://download.opensuse.org/repositories/devel:/libraries:/ACE:/micro/CentOS_7/x86_64/

Version

Applies to all ACE+TAO.

Host machine and operating system

macOS 10.14 (applies to all)

Target machine and operating system (if different from host)

macOS 10.14, linux, & recent Windows (applies to all)

AREA/CLASS/EXAMPLE AFFECTED:

Build system.

The problem effects:

The default generated makefiles.

Synopsis / Description

Is there a way to specify an external build directory (that is, building all .o files in a separate build folder like /build/x86_64-apple-darwin/ACE_wrappers/ace/ rather than /src/ACE_wrappers/ace/.obj/) with the default generated makefiles? Or do the makefiles have to be regenerated with MPC?

I'd greatly prefer building the .o files in a separate tree, so that the same (massive) source folder can be reused for multiple different targets. Or is such a thing only possible with CMake?

See https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/ace_6.3.3+dfsg-1_amd64-20160529-1422