ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM:
PentiumII 400Mhz, Windows NT SP. 6

     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL):
Microsoft Visual C++ V. 6 SP 3.

     AREA/CLASS/EXAMPLE AFFECTED:
TAO IDL Compiler

     DOES THE PROBLEM AFFECT:
         COMPILATION?
             If so, what do your $ACE_ROOT/ace/config.h

// Common defines for all compilers - that we use

#define ACE_HAS_STANDARD_CPP_LIBRARY 1
#define ACE_HAS_WINNT4 0
#define ACE_HAS_WINSOCK2 1

# if defined (__BORLANDC__)
// Borland C++
// ACE_CC_COMPILER is the preprocessor, which TAO_IDL uses
# define ACE_CC_COMPILER "CPP32.EXE"
#include "ace/config-win32.h"
#include "ace/config-win32-borland.h"
#elif defined (_MSC_VER)
// Microsoft C++
#include "ace/config-win32.h"
#endif

         LINKING?
             On Unix systems, did you run make realclean first?
         EXECUTION?
         OTHER (please specify)?
[Please indicate whether ACE, your application, or both are affected.]

     SYNOPSIS:
Have three idl files, that makes tao_idl crash, or (if one line is
removed)
generate code that doesn't compile.

     DESCRIPTION:
Having the following three idl files:

	 // ======================== ClassA.idl ========================

	 #ifndef _ClassA_idl
	 #define _ClassA_idl

	 module ModuleB {
		 interface ClassB;
		 interface Other;
	 };

	 #ifndef _ClassB_idl
	 #include "ClassB.idl"
	 #endif

	 module ModuleA {

		 interface ClassA
		 {
			 ModuleB::ClassB getB();
			 ModuleB::Other getOther();
		 };
	 };

	 #endif // _ClassA_idl

	 // ======================== ClassB.idl ========================

	 #ifndef _ClassB_idl
	 #define _ClassB_idl

	 module ModuleA {
		 interface ClassA;
	 };

	 #ifndef _ClassA_idl
	 #include "ClassA.idl"
	 #endif

	 module ModuleB {

----> // interface Other;

		 interface ClassB
		 {
			 ModuleA::ClassA getA();
			 Other getOther();
		 };

		 interface Other
		 {
			 ClassB getB();
		 };
	 };

	 #endif // _ClassB_idl

	 // ======================== ClassC.idl ========================

	 #ifndef _ClassC_idl
	 #define _ClassC_idl

	 #ifndef _ClassA_idl
	 #include "ClassA.idl"
	 #endif

	 #ifndef _ClassB_idl
	 #include "ClassB.idl"
	 #endif

	 module ModuleC {

		 interface ClassC
		 {
			 ModuleA::ClassA getA();
			 ModuleB::ClassB getB();
		 };
	 };

	 #endif // _ClassC_idl

If I don't include the marked line, tao_idl compiles the files, but the
code generated doesn't compile. MSVC++ 6 gives me the following errors:

> c:\src\idltest\tao\classbc.h(218) : error C2039: 'Other_ptr' : is not
a member of 'ModuleB'
> c:\src\idltest\tao\classbc.h(218) : error C2146: syntax error :
missing ';' before identifier 'getOther'
> c:\src\idltest\tao\classbc.h(218) : error C2433: 'Other_ptr' :
'virtual' not permitted on data declarations
> c:\src\idltest\tao\classbc.h(218) : error C2501: 'Other_ptr' :
missing storage-class or type specifiers
> c:\src\idltest\tao\classbc.h(306) : error C2039: 'Other_ptr' : is not
a member of 'ModuleB'
> c:\src\idltest\tao\classbc.h(306) : error C2146: syntax error :
missing ';' before identifier 'getOther'
> c:\src\idltest\tao\classbc.h(306) : error C2433: 'Other_ptr' :
'virtual' not permitted on data declarations
> c:\src\idltest\tao\classbc.h(306) : error C2501: 'Other_ptr' :
missing storage-class or type specifiers

This, I thought , is because 'Other' is used in interface 'ClassB'
before it is defined. So I added the
forward declaration in 'ClassB'. Now tao_idl crashes when compiling
'classB.idl' and gives the following
error message when compiling the two other files:

> tao_idl: "?", line 14: forward declared but never defined: interface
Other

This is a very simplified scenario of the problem we have, so please
don't
tell me to put all interfaces in the same file. We tried that, and it
worked,
until some day Borlands linker refused to link the program. This is a
known bug
in the Borland linker:

From: http://www.borland.com/devsupport/bcppbuilder/bugs/bcppbuilder4/b
ugs/linker.html

	 The incremental linker is currently only capable of
         importing 11914 functions from a single import
         module.
         ...
         This appears to be caused by the inability of the
         linker to grow the OBJ symbol heap.

It seems that Inprise has their own version of 'Annoying.h'.

     REPEAT BY:
[What you did to get the error; include test program or session
transcript if at all possible.  ]

     SAMPLE FIX/WORKAROUND:
[If available ]

Hi Rick,

>> I'm just beginning to use ACE so please let me know if my analysis of
>> this problem is wrong.

Ok!

>>     ACE VERSION: 5.0.12
>>
>>     HOST MACHINE and OPERATING SYSTEM: Pentium II/450 with RedHat Linux
>> 6.0
>>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>>     COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc version 2.95.2
>> 19991024 (release)
>>
>>     AREA/CLASS/EXAMPLE AFFECTED:
>>         examples/test_position_independent_malloc
>>
>>     DOES THE PROBLEM AFFECT:
>>         COMPILATION? No
>>         LINKING? No
>>         EXECUTION? No
>>         OTHER (please specify)?
>>
>>     SYNOPSIS:
>>         examples/test_position_independent_malloc will dump core if the
>>         base address is different between two runs.
>>
>>     DESCRIPTION:
>>         examples/test_position_independent_malloc does not use the
>>         position independent malloc control block.

Yikes, that sounds like an oversight.

>>     REPEAT BY:
>>         Run examples/test_position_independent_malloc twice without any
>>  arguments and it works. Both runs are using the same base address.
>>
>>         To see it fail, run the example with no arguments then run it
>>         again with arguments of '-a 0' to let the system pick a base
>>         address instead of using ACE_DEFAULT_BASE_ADDR. It will promptly
>>         dump core.
>>
>>     SAMPLE FIX/WORKAROUND:
>> --- test_position_independent_malloc.cpp.~1~ Wed Aug  4 00:15:00 1999
>> +++ test_position_independent_malloc.cpp Tue Jan 25 13:20:12 2000

Thanks for the fix.  I've integrated this into the next beta release
of ACE.

Thanks,

         Doug
--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.eng.uci.edu/~schmidt/
University of Calfornia, Irvine, 92697-2625  NET: schmidt@...

Vince writes:

>     ACE VERSION: 5.0.12
>
>     HOST MACHINE and OPERATING SYSTEM: Dual 300Mhz Intel running Windows NT
> 4.0 (SP 4)
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>     COMPILER NAME AND VERSION (AND PATCHLEVEL): Visual C++ 6.0
>
>     AREA/CLASS/EXAMPLE AFFECTED:
> ACE_High_Res_Timer::global_scale_factor(void)
>
>     DOES THE PROBLEM AFFECT:
>         COMPILATION? NO
>         LINKING? NO
>         EXECUTION? YES
>         OTHER (please specify)?
>
>     SYNOPSIS: Static variable
> ACE_High_Res_Timer::global_scale_factor_status_ is not being set to 1 in
> ACE_High_Res_Timer::global_scale_factor(void) if ACE_WIN32 is defined and
> QueryPerformanceFrequency() returns TRUE.

Right.  Darrell, would you add/move the code to set
ACE_High_Res_Timer::global_scale_factor_status_ to one
in this case, please?

>     DESCRIPTION:  The failure to set the static variable
> ACE_High_Res_Timer::global_scale_factor_status_ to 1 in
> ACE_High_Res_Timer::global_scale_factor(void) appears to result in a
> static(?) thread mutex being locked/unlocked for each call to
> ACE_High_Res_Timer::start()/stop().  Is this expected behaviour?

Yes, but only for the first call.  After the code is fixed, it
shouldn't happen on any other calls.

> Multi-threaded applications using ACE_High_Res_Timers appear to exhibit
> non-scalable performance.  In other words, it is not possible to drive such
> an application to 100% CPU utilization when each thread is doing nothing
> more than a start() and stop() of a local timer object.  Rational's Quantify
> was used to determine where the application was spending the majority of
> it's time.  It was determined that the calls to
> EnterCriticalSection/LeaveCriticalSection (caused by locking/unlocking the
> mutex) were responsible for the majority of the time.
>
>     REPEAT BY:  This should be relatively easy to test by creating an
> application that spawns n threads where each thread basically does nothing
> more than start() and stop() a high res timer.

Not necessary, after the bug is fixed.

>     SAMPLE FIX/WORKAROUND:  Comment out line 180 or set
> ACE_High_Res_Timer::global_scale_factor_status_ to 1 prior to line 180.

Thanks,
David

ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM: Dual 300Mhz Intel running Windows NT
4.0 (SP 4)
     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL): Visual C++ 6.0

     AREA/CLASS/EXAMPLE AFFECTED:
ACE_High_Res_Timer::global_scale_factor(void)

     DOES THE PROBLEM AFFECT:
         COMPILATION? NO
         LINKING? NO
         EXECUTION? YES
         OTHER (please specify)?

     SYNOPSIS: Static variable
ACE_High_Res_Timer::global_scale_factor_status_ is not being set to 1 in
ACE_High_Res_Timer::global_scale_factor(void) if ACE_WIN32 is defined and
QueryPerformanceFrequency() returns TRUE.

     DESCRIPTION:  The failure to set the static variable
ACE_High_Res_Timer::global_scale_factor_status_ to 1 in
ACE_High_Res_Timer::global_scale_factor(void) appears to result in a
static(?) thread mutex being locked/unlocked for each call to
ACE_High_Res_Timer::start()/stop().  Is this expected behaviour?
Multi-threaded applications using ACE_High_Res_Timers appear to exhibit
non-scalable performance.  In other words, it is not possible to drive such
an application to 100% CPU utilization when each thread is doing nothing
more than a start() and stop() of a local timer object.  Rational's Quantify
was used to determine where the application was spending the majority of
it's time.  It was determined that the calls to
EnterCriticalSection/LeaveCriticalSection (caused by locking/unlocking the
mutex) were responsible for the majority of the time.

     REPEAT BY:  This should be relatively easy to test by creating an
application that spawns n threads where each thread basically does nothing
more than start() and stop() a high res timer.

     SAMPLE FIX/WORKAROUND:  Comment out line 180 or set
ACE_High_Res_Timer::global_scale_factor_status_ to 1 prior to line 180.

I'm just beginning to use ACE so please let me know if my analysis of
this problem is wrong.

     ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM: Pentium II/450 with RedHat Linux
6.0
     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc version 2.95.2
19991024 (release)

     AREA/CLASS/EXAMPLE AFFECTED:
         examples/test_position_independent_malloc

     DOES THE PROBLEM AFFECT:
         COMPILATION? No
         LINKING? No
         EXECUTION? No
         OTHER (please specify)?

     SYNOPSIS:
         examples/test_position_independent_malloc will dump core if the
         base address is different between two runs.

     DESCRIPTION:
         examples/test_position_independent_malloc does not use the
         position independent malloc control block.

     REPEAT BY:
         Run examples/test_position_independent_malloc twice without any
	 arguments and it works. Both runs are using the same base address.

         To see it fail, run the example with no arguments then run it
         again with arguments of '-a 0' to let the system pick a base
         address instead of using ACE_DEFAULT_BASE_ADDR. It will promptly
         dump core.

     SAMPLE FIX/WORKAROUND:
--- test_position_independent_malloc.cpp.~1~ Wed Aug  4 00:15:00 1999
+++ test_position_independent_malloc.cpp Tue Jan 25 13:20:12 2000
@@ -14,7 +14,7 @@

  ACE_RCSID(Shared_Malloc, test_multiple_mallocs,
"test_position_independent_malloc.cpp,v 4.12 1999/08/04 05:15:00 schmidt
Exp")

-typedef ACE_Malloc <ACE_MMAP_MEMORY_POOL, ACE_Process_Mutex> MALLOC;
+typedef ACE_Malloc_T <ACE_MMAP_MEMORY_POOL, ACE_Process_Mutex,
ACE_PI_Control_Block> MALLOC;

  // Default address for memory-mapped files.
  static void *base_addr = ACE_DEFAULT_BASE_ADDR;
@@ -192,6 +192,7 @@
  template class ACE_Based_Pointer<Long_Test>;
  template class auto_ptr <MALLOC>;
  template class ACE_Auto_Basic_Ptr<MALLOC>;
+template class ACE_Malloc_T <ACE_MMAP_MEMORY_POOL, ACE_Process_Mutex,
ACE_PI_Control_Block>;
  #elif defined (ACE_HAS_TEMPLATE_INSTANTIATION_PRAGMA)
  #pragma instantiate ACE_Based_Pointer<Test_Data>
  #pragma instantiate ACE_Based_Pointer_Basic<Test_Data>
@@ -200,4 +201,5 @@
  #pragma instantiate ACE_Based_Pointer_Basic<Long>
  #pragma instantiate auto_ptr <MALLOC>
  #pragma instantiate ACE_Auto_Basic_Ptr<MALLOC>
+#pragma instantiate ACE_Malloc_T <ACE_MMAP_MEMORY_POOL,
ACE_Process_Mutex, ACE_PI_Control_Block>
  #endif /* ACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION */

Nanbor >> The problem with this change is that I don't see how I can
determine
	 Nanbor >> when to use ACE_DES_PTR_ARRAY_FREE over ACE_DES_ARRAY_FREE
with
	 Nanbor >> ACE_Array.  Does that make sense?

	 Yes. I see the problem. Each macro needs to be selected depending on
the type passed as a parameter to the ACE_ARRAY template. Not possible as
far as I know.

	 Since the code compiles on VS 6, I am starting to suspect it is a
bug or limitation of VS 5. May be time to upgrade !
	 Still I really don't understand how the ACE_DES_ARRAY_FREE works
with a pointer passed as a parameter to the template since the line in the
macro:

		 (this->array_)[i].~T ();

	 expands to: (this->array_)[i].~Notify_Constraint_Expr* ();

	 which I don't think makes sense (or maybe I just don't understand).


	 Alex



> -----Original Message-----
> From: Nanbor Wang [SMTP:nanbor@...]
> Sent: Tuesday, 25 January 2000 6:05
> To: ace-bugs@...
> Cc: Pradeep Gore
> Subject: Re: [ace-bugs] Orb Services: Compiling Notify_Filter_i.cpp
>
> Hi Alex,
>
>     >>> looking throught the code in 'Containers_T.i', I have doubts
>     >>> whether ACE_DES_ARRAY_FREE is the correct macro to use.
>
>     Doug> Can you please be more specific what you are looking at?
>     Doug> Most of this code has been around for a long time, so if
>     Doug> there were problems I suspect they would have shownup by
>     Doug> now.
>
>     >>> It appears that ACE_DES_ARRAY_FREE calls a destructor for T on
>     >>> each of the elements of the array and then frees the entire
>     >>> array using the allocator.
>
>     Doug> Yes, that's correct.
>
>     >>> However the template used by the class TAO_Notify_Filter_i is
>     >>> instantiated with the Notify_Constraint_Expr* type.
>     >>>
>     >>> ie ACE_Array<Notify_Constraint_Expr*>.
>
>     Doug> Ah, ok, it's the ACE_Array class then, right?
>
>     >>> Therefore the array is an array of pointers to
>     >>> Notify_Constraint_Expr, not an array of Notify_Constraint_Expr
>     >>> objects.
>
>     Doug> Right, that's ok.
>
>     >>> The macro attempts to call the descructor of
>     >>> Notify_Constraint_Expr*, not Notify_Constraint_Expr. Is this
>     >>> what is intended ?
>
>     Doug> Yes, that's correct.  That's how C++ works.
>
>     >>> The macro expands to template <class T> ACE_INLINE
>     >>> ACE_Array_Base<T>::~ACE_Array_Base (void) { do { if
>     >>> (this->array_) { for (size_t i = 0; i < this->max_size_; ++i)
>     >>> { (this->array_)[i].~T (); }
>     >>>
>     this-> allocator_->free (this->array_);
>     >>> } } while (0); }
>     >>>
>     >>> There also seems to be another problem with the instantiation
>     >>> of the template with Visual Studio. From the compilation error
>     >>> it seems that the T template parametre in the destructor call
>     >>> is not being expanded to the correct name.
>     >>>
>     >>> ie the line: (this->array_)[i].~T ();
>     >>>
>     >>> will expand to: (this->array_)[i].~Notify_Constraint_Expr* ();
>     >>>
>     >>> where it should expand to:
>     >>> (this->array_)[i]->~Notify_Constraint_Expr ();
>     >>>
>     >>> Also any memory pointed to be the array of pointers of type
>     >>> Notify_Constraint_Expr* is not deallocated.
>
>     Doug> Nanbor, can you please take a look at this to see what's
>     Doug> going on here and see if we need to change this macro?
>
> I think we much use a class name with ACE_Array's.  Pradeep, can you
> please check this out if this was your intention for not releasing
> those expressions?
>
>     >> A proposed solution is:
>     >> # define
>     >>
> ACE_DES_PTR_ARRAY_FREE(POINTER,SIZE,ARRAYDEALLOCATOR,CLASS,CLASSDEALLOCATO
> R) \
>     >>    do { \
>     >>         if (POINTER) \
>     >>           { \
>     >>             for (size_t i = 0; \
>     >>                  i < SIZE; \
>     >>                  ++i) \
>     >>             { \
>     >>               (POINTER)[i]->~CLASS (); \
>     >> 	  CLASSDEALLOCATOR((POINTER)[i])\
>     >>             } \
>     >>             ARRAYDEALLOCATOR(POINTER); \
>     >>           } \
>     >>       } \
>     >>    while (0)
>
> The problem with this change is that I don't see how I can determine
> when to use ACE_DES_PTR_ARRAY_FREE over ACE_DES_ARRAY_FREE with
> ACE_Array.  Does that make sense?
>
> Thanks,
>
> nanbor
>
> --
> Nanbor Wang <nanbor@...>

ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM: Dual Pentium II 500Mhz, RedHat 6.1
     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ 2.91.66

     AREA/CLASS/EXAMPLE AFFECTED:  Cannot build files in JAWS/stress
				   testing

     DOES THE PROBLEM AFFECT:
         COMPILATION?
             If so, what do your $ACE_ROOT/ace/config.h and
             $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?

		 config.h -> config-linux-lxpthreads.h
		 platform_macros.GNU -> platform_linux_lxpthread.GNU

         LINKING?
             On Unix systems, did you run make realclean first?
		 yes

         EXECUTION?
         OTHER (please specify)?
[Please indicate whether ACE, your application, or both are affected.]

     SYNOPSIS:  Cannot build the files in JAWS/stress_testing (linker
errors).

     DESCRIPTION:  I get errors like these for all the functions in
client_thread().

.obj/http_tester.o: In function `client_thread(void *)':
/root/projects/ACE_wrappers/apps/JAWS/stress_testing/http_tester.cpp:20:
undefined reference to `URL::get_protocol(void)'

Hi Alex,

	 The Notify_Filter_i.cpp compiles successfully here on NT with VS
6.

> I think we much use a class name with ACE_Array's.  Pradeep, can you
> please check this out if this was your intention for not releasing
> those expressions?
>

I used the ACE_Array to hold pointers to objects for some temporary
evaluation. The objects to those pointers were not meant to be deleted.

thanks,
Pradeep

Hi Alex,

     >>> looking throught the code in 'Containers_T.i', I have doubts
     >>> whether ACE_DES_ARRAY_FREE is the correct macro to use.

     Doug> Can you please be more specific what you are looking at?
     Doug> Most of this code has been around for a long time, so if
     Doug> there were problems I suspect they would have shownup by
     Doug> now.

     >>> It appears that ACE_DES_ARRAY_FREE calls a destructor for T on
     >>> each of the elements of the array and then frees the entire
     >>> array using the allocator.

     Doug> Yes, that's correct.

     >>> However the template used by the class TAO_Notify_Filter_i is
     >>> instantiated with the Notify_Constraint_Expr* type.
     >>>
     >>> ie ACE_Array<Notify_Constraint_Expr*>.

     Doug> Ah, ok, it's the ACE_Array class then, right?

     >>> Therefore the array is an array of pointers to
     >>> Notify_Constraint_Expr, not an array of Notify_Constraint_Expr
     >>> objects.

     Doug> Right, that's ok.

     >>> The macro attempts to call the descructor of
     >>> Notify_Constraint_Expr*, not Notify_Constraint_Expr. Is this
     >>> what is intended ?

     Doug> Yes, that's correct.  That's how C++ works.

     >>> The macro expands to template <class T> ACE_INLINE
     >>> ACE_Array_Base<T>::~ACE_Array_Base (void) { do { if
     >>> (this->array_) { for (size_t i = 0; i < this->max_size_; ++i)
     >>> { (this->array_)[i].~T (); }
     >>>
     this-> allocator_->free (this->array_);
     >>> } } while (0); }
     >>>
     >>> There also seems to be another problem with the instantiation
     >>> of the template with Visual Studio. From the compilation error
     >>> it seems that the T template parametre in the destructor call
     >>> is not being expanded to the correct name.
     >>>
     >>> ie the line: (this->array_)[i].~T ();
     >>>
     >>> will expand to: (this->array_)[i].~Notify_Constraint_Expr* ();
     >>>
     >>> where it should expand to:
     >>> (this->array_)[i]->~Notify_Constraint_Expr ();
     >>>
     >>> Also any memory pointed to be the array of pointers of type
     >>> Notify_Constraint_Expr* is not deallocated.

     Doug> Nanbor, can you please take a look at this to see what's
     Doug> going on here and see if we need to change this macro?

I think we much use a class name with ACE_Array's.  Pradeep, can you
please check this out if this was your intention for not releasing
those expressions?

     >> A proposed solution is:
     >> # define
     >>
ACE_DES_PTR_ARRAY_FREE(POINTER,SIZE,ARRAYDEALLOCATOR,CLASS,CLASSDEALLOCATOR) \
     >>    do { \
     >>         if (POINTER) \
     >>           { \
     >>             for (size_t i = 0; \
     >>                  i < SIZE; \
     >>                  ++i) \
     >>             { \
     >>               (POINTER)[i]->~CLASS (); \
     >> 	  CLASSDEALLOCATOR((POINTER)[i])\
     >>             } \
     >>             ARRAYDEALLOCATOR(POINTER); \
     >>           } \
     >>       } \
     >>    while (0)

The problem with this change is that I don't see how I can determine
when to use ACE_DES_PTR_ARRAY_FREE over ACE_DES_ARRAY_FREE with
ACE_Array.  Does that make sense?

Thanks,

nanbor

--
Nanbor Wang <nanbor@...>

Fabrizio writes:

>     SYNOPSIS:
> I have either the message
> ACE_SV_Semaphore_Complex : Invalid argument
> or
> ACE_SV_Semaphore_Complex : No space left on device
> and my process is not able to fork anymore.
>
>     DESCRIPTION:
> My program spawns several child processes that communicate between them
> through shared memory.
> After 3 or 4 processes have been spawned, at next fork, I have the
> errors mentioned above.

It looks like you're running out of system resources.  You
try looking at the limit and ulimit man pages.  And, ask
your system administrator for assistance.

Thanks,
David

Hi Alex,

>>  looking throught the code in 'Containers_T.i', I have doubts whether
>> ACE_DES_ARRAY_FREE is the correct macro to use.

Can you please be more specific what you are looking at?  Most of this
code has been around for a long time, so if there were problems I
suspect they would have shownup by now.

>>  It appears that ACE_DES_ARRAY_FREE calls a destructor for T on
>> each of the elements of the array and then frees the entire array
>> using the allocator.

Yes, that's correct.

>> However the template used by the class TAO_Notify_Filter_i is instantiated
>> with the Notify_Constraint_Expr* type.
>>
>> ie ACE_Array<Notify_Constraint_Expr*>.

Ah, ok, it's the ACE_Array class then, right?

>> Therefore the array is an array of pointers to Notify_Constraint_Expr, not
>> an array of Notify_Constraint_Expr objects.

Right, that's ok.

>> The macro attempts to call the descructor of Notify_Constraint_Expr*, not
>> Notify_Constraint_Expr. Is this what is intended ?

Yes, that's correct.  That's how C++ works.

>> The macro expands to
>> template <class T> ACE_INLINE
>> ACE_Array_Base<T>::~ACE_Array_Base (void)
>> {
>>   do
>>   {
>> 	  if (this->array_)
>> 	  {
>> 		  for (size_t i = 0; i < this->max_size_; ++i)
>> 		  {
>> 			  (this->array_)[i].~T ();
>> 		  }
>>
>> 		  this->allocator_->free (this->array_);
>> 	  }
>>   } while (0);
>> }
>>
>> There also seems to be another problem with the instantiation of the
>> template with Visual Studio. From the compilation error it seems that the T
>> template parametre in the destructor call is not being expanded to the
>> correct name.
>>
>> ie the line:
>>  (this->array_)[i].~T ();
>>
>> will expand to:
>>  (this->array_)[i].~Notify_Constraint_Expr* ();
>>
>> where it should expand to:
>>  (this->array_)[i]->~Notify_Constraint_Expr ();
>>
>> Also any memory pointed to be the array of pointers of type
>> Notify_Constraint_Expr* is not deallocated.

Nanbor, can you please take a look at this to see what's going on here
and see if we need to change this macro?

Thanks,

         Doug

>> A proposed solution is:
>> # define
>> ACE_DES_PTR_ARRAY_FREE(POINTER,SIZE,ARRAYDEALLOCATOR,CLASS,CLASSDEALLOCATOR)
>> \
>>    do { \
>>         if (POINTER) \
>>           { \
>>             for (size_t i = 0; \
>>                  i < SIZE; \
>>                  ++i) \
>>             { \
>>               (POINTER)[i]->~CLASS (); \
>> 	  CLASSDEALLOCATOR((POINTER)[i])\
>>             } \
>>             ARRAYDEALLOCATOR(POINTER); \
>>           } \
>>       } \
>>    while (0)
--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.eng.uci.edu/~schmidt/
University of Calfornia, Irvine, 92697-2625  NET: schmidt@...

Subject: problem with ACE on Digital Unix

     ACE VERSION:   version 4.2

     HOST MACHINE and OPERATING SYSTEM:
>> uname -a
>> OSF1 ASCSAWS3 V4.0 1091 alpha

     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>> gcc -v : 2.7.2.1
>> make -v: GNU make 3.74

     AREA/CLASS/EXAMPLE AFFECTED:


  THE PROBLEM AFFECT:
         EXECUTION
I get the problem at runtime.
Both ACE and my application are affected.


     SYNOPSIS:
I have either the message
ACE_SV_Semaphore_Complex : Invalid argument
or
ACE_SV_Semaphore_Complex : No space left on device
and my process is not able to fork anymore.




     DESCRIPTION:
My program spawns several child processes that communicate between them
through shared memory.
After 3 or 4 processes have been spawned, at next fork, I have the
errors mentioned above.




     REPEAT BY:
If  I run the tests SV_Shared_Memory_Test and running Mutex_Test I have
the following error messages:

running SV_Shared_Memory_Test
ACE_SV_Semaphore_Simple::ACE_SV_Semaphore_Simple: No space left on
device
ACE_ASSERT: file SV_Shared_Memory_Test.cpp, line 39 assertion failed for

'mutex.open (SEM_KEY_1, ACE_SV_Semaphore_Complex::ACE_CREATE, 0) != -1'.

ACE_ASSERT: file SV_Shared_Memory_Test.cpp, line 71 assertion failed for

'mutex.open (SEM_KEY_1, ACE_SV_Semaphore_Complex::ACE_CREATE, 0) != -1'.

"SV_Shared_Memory_Test" FAILED with exit status 255!!!!
Error in log file no line with Ending
ACE_ASSERT: file SV_Shared_Memory_Test.cpp, line 39 assertion failed for

'mutex.open (SEM_KEY_1, ACE_SV_Semaphore_Complex::ACE_CREATE, 0) != -1'.

ACE_ASSERT: file SV_Shared_Memory_Test.cpp, line 71 assertion failed for

'mutex.open (SEM_KEY_1, ACE_SV_Semaphore_Complex::ACE_CREATE, 0) != -1'.




running Mutex_Test
ACE_ASSERT: file Mutex_Test.cpp, line 40 assertion failed for
'pm->acquire () == 0'.
"Mutex_Test" FAILED with exit status 255!!!!
ACE_ASSERT: file Mutex_Test.cpp, line 40 assertion failed for
'pm->acquire () == 0'.
Error in log file no line with Ending
ACE_ASSERT: file Mutex_Test.cpp, line 40 assertion failed for
'pm->acquire () == 0'.
ACE_ASSERT: file Mutex_Test.cpp, line 40 assertion failed for
'pm->acquire () == 0'.


     SAMPLE FIX/WORKAROUND: N/A

Please help!!

-- Fabrizio --

--
.......................................................................
Fabrizio Pacini  <fpacini@...>
DATAMAT  Ingegneria dei Sistemi S.p.A.
Space & Environment Unit - G/S Programs Group
Unit Home Page: http://www.datamat.it/progetti/english/space.htm
Via Laurentina, 760 - 00143 - Rome - Italy
Ph.: +39-06-5027.4573  -  Fax: +39-06-5020775
WWW Site:   http://www.datamat.it

Doug,
	 looking throught the code in 'Containers_T.i', I have doubts whether
ACE_DES_ARRAY_FREE is the correct macro to use.

	 It appears that ACE_DES_ARRAY_FREE calls a destructor for T on each
of the elements of the array and then frees the entire array using the
allocator.

However the template used by the class TAO_Notify_Filter_i is instantiated
with the Notify_Constraint_Expr* type.

ie ACE_Array<Notify_Constraint_Expr*>.

Therefore the array is an array of pointers to Notify_Constraint_Expr, not
an array of Notify_Constraint_Expr objects.
The macro attempts to call the descructor of Notify_Constraint_Expr*, not
Notify_Constraint_Expr. Is this what is intended ?

The macro expands to
template <class T> ACE_INLINE
ACE_Array_Base<T>::~ACE_Array_Base (void)
{
   do
   {
	   if (this->array_)
	   {
		   for (size_t i = 0; i < this->max_size_; ++i)
		   {
			   (this->array_)[i].~T ();
		   }

		   this->allocator_->free (this->array_);
	   }
   } while (0);
}

There also seems to be another problem with the instantiation of the
template with Visual Studio. From the compilation error it seems that the T
template parametre in the destructor call is not being expanded to the
correct name.

ie the line:
	 (this->array_)[i].~T ();

will expand to:
	 (this->array_)[i].~Notify_Constraint_Expr* ();

where it should expand to:
	 (this->array_)[i]->~Notify_Constraint_Expr ();


Also any memory pointed to be the array of pointers of type
Notify_Constraint_Expr* is not deallocated.

A proposed solution is:
# define
ACE_DES_PTR_ARRAY_FREE(POINTER,SIZE,ARRAYDEALLOCATOR,CLASS,CLASSDEALLOCATOR)
\
    do { \
         if (POINTER) \
           { \
             for (size_t i = 0; \
                  i < SIZE; \
                  ++i) \
             { \
               (POINTER)[i]->~CLASS (); \
	   CLASSDEALLOCATOR((POINTER)[i])\
             } \
             ARRAYDEALLOCATOR(POINTER); \
           } \
       } \
    while (0)

thanks,
Alex.

> -----Original Message-----
> From: Douglas C. Schmidt [SMTP:schmidt@...]
> Sent: Tuesday, 18 January 2000 15:04
> To: ace-bugs@...; bala@...
> Subject: Re: [ace-bugs] Orb Services: Compiling Notify_Filter_i.cpp
>
> Hi Alex,
>
> >>     ACE VERSION: 5.0.12
> >>
> >>     HOST MACHINE and OPERATING SYSTEM:
> >> 		 Intel Celeron / Windows NT 4.0 SP3
> >>
> >>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
> >> 		 MS VS v5.0 sp3
> >>
> >>     AREA/CLASS/EXAMPLE AFFECTED:
> >> The Notify_Filter_i.cpp failed to compile
> >>
> >>     SYNOPSIS:
> >> During comilation of the ORB Services DLL project the file
> >> Notify_Filter_i.cpp fails to compile.
> >> All depend projects have compiled correctly.
> >>
> >>     DESCRIPTION:
> >> The Error the compiler produces is in the file
> >>
> >> Containers_T.i(311) : error C2300:
> >> 'TAO_Notify_Filter_i::Notify_Constraint_Expr' :
> >>  class does not have a destructor called '~T'
> >>
> >> The problem seems to be with the line.
> >> 	  ACE_DES_ARRAY_FREE (this->array_,
> >>                       this->max_size_,
> >>                       this->allocator_->free,
> >>                       T);
>
> This sounds like some type of configuration problem with ACE or your
> version of MSVC++.  I don't think we have any MSVC 5.0 versions
> running in our lab anymore, so you may need to help track this down
> since I don't think we can reproduce it at WU or UCI.
>
> Bala, since Pradeep isn't back from India yet, can you please add this
> to bugzilla so we can track it?  Please attribute it to
>
> Alex Scholte <Alex.Scholte@...>
>
> Thanks,
>
>         Doug
> --
> Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
> Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
> 616E Engineering Tower                       WEB:
> www.eng.uci.edu/~schmidt/
> University of Calfornia, Irvine, 92697-2625  NET: schmidt@...

Hi Thierry,

>> I have built successfully ACE5+TAO1 on my PC/Linux and it looks good
>> from my first test, but I have a problem when I try to build ACE on an
>> SGI/IRIX 6.5:
>> I am using the IRIX native C++ compiler with
>>    ln -sf config-irix6.x-sgic++.h config.h under ace
>>    ln -sf platform_irix6.x_sgic++.GNU platform_macros.GNU under
>>       include/makeinclude
>>
>> When I try to run the building Makefile for ACE from the clone
>> directory for Irix, I obtain the following error message:
>> make -f ../Makefile clone
>> make: file `/Misc/ACE/ACE_wrappers/include/makeinclude/wrapper_macros.G
>> NU' line 130: Must be a separator (: or ::) for rules (bu39)
>> make: file `/Misc/ACE/ACE_wrappers/include/makeinclude/wrapper_macros.G
>> NU' line 130: Must be a separator (: or ::) for rules (bu39)
>> make: file `/Misc/ACE/ACE_wrappers/include/makeinclude/wrapper_macros.G
>> NU' line 130: Syntax error
>>
>> Could someone provide me with a work-around? Thanks in advance

Please make sure that you're using GNU Make.  If you read

$ACE_ROOT/ACE-INSTALL.html

it explains all of this.

Thanks,

         Doug
--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.eng.uci.edu/~schmidt/
University of Calfornia, Irvine, 92697-2625  NET: schmidt@...

I have built successfully ACE5+TAO1 on my PC/Linux and it looks good
from my first test, but I have a problem when I try to build ACE on an
SGI/IRIX 6.5:
I am using the IRIX native C++ compiler with
    ln -sf config-irix6.x-sgic++.h config.h under ace
    ln -sf platform_irix6.x_sgic++.GNU platform_macros.GNU under
       include/makeinclude

When I try to run the building Makefile for ACE from the clone
directory for Irix, I obtain the following error message:
make -f ../Makefile clone
make: file `/Misc/ACE/ACE_wrappers/include/makeinclude/wrapper_macros.G
NU' line 130: Must be a separator (: or ::) for rules (bu39)
make: file `/Misc/ACE/ACE_wrappers/include/makeinclude/wrapper_macros.G
NU' line 130: Must be a separator (: or ::) for rules (bu39)
make: file `/Misc/ACE/ACE_wrappers/include/makeinclude/wrapper_macros.G
NU' line 130: Syntax error

Could someone provide me with a work-around? Thanks in advance

For your information, I am in charge of evaluating COTS software
solutions for the development of aircraft engineering and piloted
simulators.
Our platform is Unix(Irix/Aix/Solaris)/Linux(PC) and NT based.


Best Regards

AREA/CLASS/EXAMPLE AFFECTED:
     Error in g++dep causes bad substitutions in Makefiles.

     SYNOPSIS:
     Any where a ".o" or ".h" is encountered causes a substitution to occur.

     SAMPLE FIX/WORKAROUND:

--- /usr/local/src/ACE_wrappers/bin/g++dep.old      Thu Jan 20 09:49:51 2000
+++ /usr/local/src/ACE_wrappers/bin/g++dep      Thu Jan 20 09:45:53 2000
@@ -82,13 +82,13 @@
  if [ $DO_ACE_MAKE_DEPEND -eq 1 ]
  then
    SCRIPT=${TMP}_script
-  echo "s;\([-a-zA-Z0-9._]*\)\.o:;\\" > $SCRIPT
+  echo "s;\([-a-zA-Z0-9._]+\)\.o:;\\" > $SCRIPT
    echo ".obj/\1.o .obj/\1.${SOEXT} ${VSHDIR}\1.o ${VSHDIR}\1.${SOEXT}:;" >>
$SCRIPT
    TMP2=${TMP}_2
    cat $TMP | \
    sed \
        -e '/$(ACE_ROOT)\/ace\/config[^\.]*\.h/d' \
-      -e "s; /[-a-zA-Z0-9_./]*\.h;;g" \
+      -e "s; /[-a-zA-Z0-9_./]+\.h;;g" \
        -f $SCRIPT > $TMP2
    mv $TMP2 $TMP
    rm -f $TMP2


Not a brilliant solution - but I think it is what was originally intended.



Chris

Dave Hall writes:

>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>         Gespac PCIPPC3 (Power PC 603E)
>         Tornado 1.0.1

> Make sure the compile uses -fno-implicit-template
> AND the macro ACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
> is turned on.

-fno-implicit-templates is broken in the Tornado 1.0.1 g++
for some CPUs.  Maybe PPC 603E, though I'd be a bit surprised.
You might ask Wind River about it.  But first, I'd check to
make sure that -fno-implicit-templates (with trailing s) is
really enabled and doing the expected thing.

Thanks,
David

> From: Douglas C. Schmidt [mailto:schmidt@...]
>
> >> I've been away from using ACE for about a year,
>
> Right -- weren't you at John Hopkins APL last time?
>

Right!  R&D (for 12 years) was great, but the allure of working
on commercial products became too strong.

>
> >> Here's a bug (I think) with ACE_Process_Manager on WIN32.
>
> Great, thanks for reporting it.  I've added your fix to the next beta
> release.
>

Thank you.

Greg Gallant

Hi Gret,

>> I've been away from using ACE for about a year,

Right -- weren't you at John Hopkins APL last time?

>> and am happy to be able to get back to it.

Cool!

>> Here's a bug (I think) with ACE_Process_Manager on WIN32.

Great, thanks for reporting it.  I've added your fix to the next beta
release.

Take care,

         Doug
--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.eng.uci.edu/~schmidt/
University of Calfornia, Irvine, 92697-2625  NET: schmidt@...

Hi Alex,

>>     ACE VERSION: 5.0.12
>>
>>     HOST MACHINE and OPERATING SYSTEM:
>> 		 Intel Celeron / Windows NT 4.0 SP3
>>
>>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>> 		 MS VS v5.0 sp3
>>
>>     AREA/CLASS/EXAMPLE AFFECTED:
>> The Notify_Filter_i.cpp failed to compile
>>
>>     SYNOPSIS:
>> During comilation of the ORB Services DLL project the file
>> Notify_Filter_i.cpp fails to compile.
>> All depend projects have compiled correctly.
>>
>>     DESCRIPTION:
>> The Error the compiler produces is in the file
>>
>> Containers_T.i(311) : error C2300:
>> 'TAO_Notify_Filter_i::Notify_Constraint_Expr' :
>>  class does not have a destructor called '~T'
>>
>> The problem seems to be with the line.
>> 	  ACE_DES_ARRAY_FREE (this->array_,
>>                       this->max_size_,
>>                       this->allocator_->free,
>>                       T);

This sounds like some type of configuration problem with ACE or your
version of MSVC++.  I don't think we have any MSVC 5.0 versions
running in our lab anymore, so you may need to help track this down
since I don't think we can reproduce it at WU or UCI.

Bala, since Pradeep isn't back from India yet, can you please add this
to bugzilla so we can track it?  Please attribute it to

Alex Scholte <Alex.Scholte@...>

Thanks,

         Doug
--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.eng.uci.edu/~schmidt/
University of Calfornia, Irvine, 92697-2625  NET: schmidt@...

Sorry if this has been posted twice; I seem to be having trouble with our
mail server.

>     ACE VERSION: 5.0.12
>
>     HOST MACHINE and OPERATING SYSTEM:
> 		 Intel Celeron / Windows NT 4.0 SP3
>
>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
> 		 MS VS v5.0 sp3
>
>     AREA/CLASS/EXAMPLE AFFECTED:
> The Notify_Filter_i.cpp failed to compile
>
>     SYNOPSIS:
> During comilation of the ORB Services DLL project the file
> Notify_Filter_i.cpp fails to compile.
> All depend projects have compiled correctly.
>
>     DESCRIPTION:
> The Error the compiler produces is in the file
>
> Containers_T.i(311) : error C2300:
> 'TAO_Notify_Filter_i::Notify_Constraint_Expr' :
>  class does not have a destructor called '~T'
>
> The problem seems to be with the line.
> 	  ACE_DES_ARRAY_FREE (this->array_,
>                       this->max_size_,
>                       this->allocator_->free,
>                       T);
>
>     REPEAT BY:
> Compile
>
>
> regards Alex

ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM:
			 Intel Celeron / Windows NT 4.0 SP3

     COMPILER NAME AND VERSION (AND PATCHLEVEL):
			 MS VS v5.0 sp3

     AREA/CLASS/EXAMPLE AFFECTED:
The Notify_Filter_i.cpp failed to compile

     SYNOPSIS:
During comilation of the ORB Services DLL project the file
Notify_Filter_i.cpp fails to compile.
All depend projects have compiled correctly.

     DESCRIPTION:
The Error the compiler produces is in the file

Containers_T.i(311) : error C2300:
'TAO_Notify_Filter_i::Notify_Constraint_Expr' :
	 class does not have a destructor called '~T'

The problem seems to be with the line.
	   ACE_DES_ARRAY_FREE (this->array_,
                       this->max_size_,
                       this->allocator_->free,
                       T);

     REPEAT BY:
Compile


regards Alex

Hi all,

I've been away from using ACE for about a year, and am happy to be
able to get back to it.  Here's a bug (I think) with
ACE_Process_Manager on WIN32.

Greg Gallant

     ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM:
       (P450, 128Meg), (NT4 SP5)
     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL):
       VC++ 6.0 SP3

     AREA/CLASS/EXAMPLE AFFECTED:
       class ACE_Process_Manager does not clean its Exit_Handlers up
properly.

     DOES THE PROBLEM AFFECT:
         COMPILATION?
             No.
         LINKING?
             No.
         EXECUTION?
             Yes. Especially noticeable when ACE_Process_Manager is *not* a
             singleton.
         OTHER (please specify)?

     SYNOPSIS:
       Under WIN32, ACE_Process_Manager registers itself as an event handler
       with ACE_Reactor, but does not properly unregister itself when it
       closes.

     DESCRIPTION:
       For error to be noticed, you must instantiate ACE_Process_Manager with
       an ACE_Reactor.  ACE_Process_Manager should *not* be run as a
singleton.
       It must be instantiated such that it will be destroyed *before* the
       ACE_Reactor is destroyed.

       When you call ACE_Process_Manager::spawn, the newly created process is
       added to the ACE_Process_Manager's process table and (under WIN32) the
       ACE_Process_Manager is registered as an event handler for the new
       process (ace/Process_Manager.cpp, line 523) using this call:

          r->register_handler (this, proc->gethandle ());

       This will happen for every process spawned. Thus, ACE_Process_Manager
       will potentially be associated with more than one WIN32 process
handle.

       When the ACE_Process_Manager is destroyed, the dtor calls
       ACE_Process_Manager::close which (for WIN32) attempts to remove
       ACE_Process_Manager as an Event_Handler from the ACE_Reactor using the
       following code (ace/Process_Manager.cpp, line 256)

          this->reactor ()->remove_handler (this, 0);

       This version of ACE_Reactor::remove_handler is:

          int ACE_Reactor::remove_handler
          (
                ACE_Event_Handler *event_handler,
                ACE_Reactor_Mask mask
          );

       It calls event_handler->get_handle() to obtain the handle to which
       'event_handler' is associated.  The problem is that
       ACE_Process_Manager::get_handle returns ACE_INVALID_HANDLE, so the
       ACE_Reactor never properly unregisters the ACE_Process_Manager.


     REPEAT BY:
       Here is a sample program that will replicate the error...

       #include "ace/OS.h"
       #include "ace/Process_Manager.h"

       static int
       run_process ()
       {
          ACE_Process_Manager* ace_process_mgr;
          ACE_NEW_RETURN (
             ace_process_mgr,
             ACE_Process_Manager (
                ACE_Process_Manager::DEFAULT_SIZE,
                ACE_Reactor::instance ()
             ),
             -1
          );

          // Spawn a process ...
          ACE_Process_Options options;
          options.command_line (ASYS_TEXT ("cmd.exe"));
          pid_t pid = ace_process_mgr->spawn (options);

          if (pid < 0)
             return -1;

          // Wait a bit...
          ACE_OS::sleep (5);

          // Now clean up ACE_Process_Manager
          if (ace_process_mgr->terminate (pid) == 0)
             if (ace_process_mgr->wait (pid) == pid) {
                delete ace_process_mgr;
                return 0;
             }
          return -1;
       }

       int
       main (int argc, char** argv)
       {
          ACE::init ();
          if (-1 == run_process ()) {
             ACE_DEBUG (
                (LM_DEBUG,
                 ASYS_TEXT ("Unexpected problem with this sample\n"))
             );
          }

          // Exception will occur on close of ACE_Reactor singleton.
          ACE::fini ();
          return 0;
       }

     SAMPLE FIX/WORKAROUND:

       Here is a patch to fix the problem...

*** Process_Panager.cpp Tue Dec 28 16:43:18 1999
--- new_Process_Manager.cpp Mon Jan 17 16:24:14 2000
***************
*** 252,262 ****
--- 252,264 ----
   {
     ACE_TRACE ("ACE_Process_Manager::close");

+ #if !defined (ACE_WIN32)
     if (this->reactor ())
       {
         this->reactor ()->remove_handler (this, 0);
         this->reactor (0);
       }
+ #endif /*  !ACE_WIN32  */

     ACE_MT (ACE_GUARD_RETURN (ACE_Thread_Mutex, ace_mon, this->lock_, -1));

***************
*** 580,585 ****
--- 582,594 ----
            0);
         this->process_table_[i].exit_notify_ = 0;
       }
+
+ #if defined (ACE_WIN32)
+   ACE_Reactor *r = this->reactor ();
+   if (r != 0)
+     r->remove_handler (this->process_table_[i].process_->gethandle (),
+                        ACE_Event_Handler::DONT_CALL);
+ #endif /*  ACE_WIN32  */

     this->process_table_[i].process_->unmanage ();

Greets all,

Although for many people here, this is likely common knowledge,
I recently discovered that Windows95/98 does not inherently
support UNICODE programming.

Quoting from an MSDN page:

http://msdn.microsoft.com/library/psdk/win95/chilimit_21rn.htm

"By design, functions that take string parameters can handle either Unicode™
(wide character) or ANSI strings. However, Windows 95/98 does not implement the
Unicode (or wide character) version of most functions. With few exceptions,
these functions are implemented as stubs that simply return an error value.
However,
Windows 95/98 does provide Unicode implementations of the following functions."

This would seem to explain difficulties in producing UNICODE ACE
apps under Win98.

Cheers all,
Jonathan.


Jonathan Lindo wrote:
>
>     ACE VERSION: 5.0.12
>
>     HOST MACHINE and OPERATING SYSTEM:
>
> Pentium III 500Mhz
> Windows 98
>
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
> MSVC 6.0 Professional SP3
>
>     AREA/CLASS/EXAMPLE AFFECTED:
>
> All applications linked against ACEUD.DLL fail at run-time
> under Win98.
>
>     DOES THE PROBLEM AFFECT:
>         COMPILATION?
>
> Compilation is fine, but here is my config.h:
>
> ---------------
> #define ACE_HAS_WINNT4 0
> #define ACE_HAS_STANDARD_CPP_LIBRARY 1
>
> #include "ace/config-win32.h"
> ---------------
>
>         LINKING?
>
> No problems linking.
>
>         EXECUTION?
>
> At execution, the app crashes immediately during Object_Manager
> initialization.
>
> Stack trace from MSVC after the crash is as follows:
>
> KERNEL32! bff8ac13()
> ACE_OS::cond_destroy(ACE_cond_t * 0x009704c0) line 5523 + 12 bytes
> ACE_OS::rwlock_init(ACE_rwlock_t * 0x009704a4, int 1, const unsigned short *
0x00000000, void * 0x00000000) line 5493 + 12 bytes
> ACE_RW_Mutex::ACE_RW_Mutex(int 1, const unsigned short * 0x00000000, void *
0x00000000) line 199+ 21 bytes
> ACE_RW_Thread_Mutex::ACE_RW_Thread_Mutex(const unsigned short * 0x00000000,
void * 0x00000000) line 1002
>
ACE_Cleanup_Adapter<ACE_RW_Thread_Mutex>::ACE_Cleanup_Adapter<ACE_RW_Thread_Mute\
x>() line 9 + 58 bytes
> ACE_Object_Manager::init() line 197 + 37 bytes
> ACE_Object_Manager::ACE_Object_Manager() line 278
> main(int 1, char * * 0x00970d20) line 90 + 52 bytes
> mainCRTStartup() line 338 + 17 bytes
> KERNEL32! bff8b560()
> KERNEL32! bff8b412()
> KERNEL32! bff89dd5()
>
> Crash occurs in ACE_OS::cond_destroy():
>
> int
> ACE_OS::cond_destroy (ACE_cond_t *cv)
> {
>   ACE_TRACE ("ACE_OS::cond_destroy");
> # if defined (ACE_HAS_THREADS)
> #   if defined (ACE_HAS_WTHREADS)
>   ACE_OS::event_destroy (&cv->waiters_done_);
> #   elif defined (VXWORKS) || defined (ACE_PSOS)
>   ACE_OS::sema_destroy (&cv->waiters_done_);
> #   endif /* VXWORKS */
>   ACE_OS::thread_mutex_destroy (&cv->waiters_lock_);
>   return ACE_OS::sema_destroy (&cv->sema_);
> # else
>   ACE_UNUSED_ARG (cv);
>   ACE_NOTSUP_RETURN (-1);
> # endif /* ACE_HAS_THREADS */
> }
>
>         OTHER (please specify)?
>
>     SYNOPSIS:
>
> Test apps compiled against the ACED.DLL run without problems.
> Compiling and linking against Unicode ACEUD.DLL causes a
> run-time crash.
>
>     DESCRIPTION:
>
> After modifying test apps Task_Test and SOCK_Test to use the
> Unicode DLL by changing aced.dll to aceud.dll in the link line,
> and adding UNICODE to the preprocessor defines, the app crashes
> immediately.
>
>     REPEAT BY:
>
> Under Windows98, compile and link any app using the Unicode
> ACEUD.DLL and defining UNICODE as a preprocessor.
>
>     SAMPLE FIX/WORKAROUND:
>
> None.

ACE VERSION: 5.0.12

My machine is a Sun Ultra 5 333. I use Solaris 7 i.e. SunOS 5.7.
The target is this machine. I have attempted to build ACE using the
Workshop Compiler v4.2 at patch level 104631-07.
The output of CC -V yields:
CC: WorkShop Compilers 4.2 16 Jun 1998 C++ 4.2 patch 104631-07

     AREA/CLASS/EXAMPLE AFFECTED:
[What example failed?  What module failed to compile?]
The problem affects compilation. It fails. The contents of my config.h
are:

/* -*- C++ -*- */
// $Id: config-sunos5.4-sunc++-4.x.h,v 4.28 1998/12/29 15:47:28 levine Exp $

// The following configuration file is designed to work for SunOS 5.4
// platforms using the SunC++ 4.0.x compiler.

#ifndef ACE_CONFIG_H
#define ACE_CONFIG_H

#if ! defined (__ACE_INLINE__)
# define __ACE_INLINE__
#endif /* ! __ACE_INLINE__ */

#define ACE_HAS_TEMPLATE_SPECIALIZATION

// Maximum compensation (10 ms) for early return from timed ::select ().
#if !defined (ACE_TIMER_SKEW)
# define ACE_TIMER_SKEW 10 * 1000
#endif /* ACE_TIMER_SKEW */

// Optimize ACE_Handle_Set for select().
#define ACE_HAS_HANDLE_SET_OPTIMIZED_FOR_SELECT

(config.h is a dynamic link to config-sunos5.4-sunc++-4.x.h)

--

My platform_macros.GNU is a dynamic link to platform_sunos5_sunc++.GNU.

     SYNOPSIS:
Compilation fails with numerous compile-time errors.

     DESCRIPTION:
During the make I receive (multiple times) one warning and three errors.
For example:

make[2]: Leaving directory `/space/ACE/ACE_wrappers/examples/Naming'
make[2]: Entering directory `/space/ACE/ACE_wrappers/examples/Reactor'
make[3]: Entering directory `/space/ACE/ACE_wrappers/examples/Reactor/Dgram'
CC -mt -g -features=castop -DACE_LACKS_RTTI -noex   -I.
-I/space/ACE/ACE_wrappers  -c -o .obj/CODgram.o CODgram.cpp
"/space/ACE/ACE_wrappers/ace/OS.h", line 2815: Error: Only one of a set of
overloaded functions can be "C" or "Pascal".
"/space/ACE/ACE_wrappers/ace/OS.i", line 5010: Warning (Anachronism): Formal
argument 5 of type timeval* in call to select(int, fd_set*, fd_set*, fd_set*,
timeval*) is being passed const timeval*.
"/space/ACE/ACE_wrappers/ace/OS.i", line 5010: Note: Type "CC -migration" for
more on anachronisms.
"/space/ACE/ACE_wrappers/ace/OS.i", line 5031: Warning (Anachronism): Formal
argument 5 of type timeval* in call to select(int, fd_set*, fd_set*, fd_set*,
timeval*) is being passed const timeval*.
"/space/ACE/ACE_wrappers/ace/OS.i", line 10305: Warning (Anachronism): Formal
argument 5 of type timeval* in call to select(int, fd_set*, fd_set*, fd_set*,
timeval*) is being passed const timeval*.
"/space/ACE/ACE_wrappers/ace/Signal.i", line 154: Error: Cannot assign void(*)()
to void(*)(int).
2 Error(s) and 3 Warning(s) detected.

The modules causing the errors are exclusively Signal.i and OS.i.

Repeatability:
This is a compile-time bug. It is 100% repeatable.
I have attempted to use g++ 2.95, with similar results, using
platform_macro.GNU = platform_sunos5_g++.GNU with
config.h = config-sunos5.7.h AND config-sunos5.4-g++.h. No luck.

_____________________________________________
David Gillies
INTACGlobalInvestments.com Ltd.
San Jose
Costa Rica

email: root@...
_____________________________________________

ACE VERSION: 5.0.12

     HOST MACHINE and OPERATING SYSTEM:

Pentium III 500Mhz
Windows 98

     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL):

MSVC 6.0 Professional SP3

     AREA/CLASS/EXAMPLE AFFECTED:

All applications linked against ACEUD.DLL fail at run-time
under Win98.

     DOES THE PROBLEM AFFECT:
         COMPILATION?

Compilation is fine, but here is my config.h:

---------------
#define ACE_HAS_WINNT4 0
#define ACE_HAS_STANDARD_CPP_LIBRARY 1

#include "ace/config-win32.h"
---------------

         LINKING?

No problems linking.

         EXECUTION?

At execution, the app crashes immediately during Object_Manager
initialization.

Stack trace from MSVC after the crash is as follows:

KERNEL32! bff8ac13()
ACE_OS::cond_destroy(ACE_cond_t * 0x009704c0) line 5523 + 12 bytes
ACE_OS::rwlock_init(ACE_rwlock_t * 0x009704a4, int 1, const unsigned short *
0x00000000, void * 0x00000000) line 5493 + 12 bytes
ACE_RW_Mutex::ACE_RW_Mutex(int 1, const unsigned short * 0x00000000, void *
0x00000000) line 199+ 21 bytes
ACE_RW_Thread_Mutex::ACE_RW_Thread_Mutex(const unsigned short * 0x00000000, void
* 0x00000000) line 1002
ACE_Cleanup_Adapter<ACE_RW_Thread_Mutex>::ACE_Cleanup_Adapter<ACE_RW_Thread_Mute\
x>() line 9 + 58 bytes
ACE_Object_Manager::init() line 197 + 37 bytes
ACE_Object_Manager::ACE_Object_Manager() line 278
main(int 1, char * * 0x00970d20) line 90 + 52 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! bff8b560()
KERNEL32! bff8b412()
KERNEL32! bff89dd5()

Crash occurs in ACE_OS::cond_destroy():

int
ACE_OS::cond_destroy (ACE_cond_t *cv)
{
   ACE_TRACE ("ACE_OS::cond_destroy");
# if defined (ACE_HAS_THREADS)
#   if defined (ACE_HAS_WTHREADS)
   ACE_OS::event_destroy (&cv->waiters_done_);
#   elif defined (VXWORKS) || defined (ACE_PSOS)
   ACE_OS::sema_destroy (&cv->waiters_done_);
#   endif /* VXWORKS */
   ACE_OS::thread_mutex_destroy (&cv->waiters_lock_);
   return ACE_OS::sema_destroy (&cv->sema_);
# else
   ACE_UNUSED_ARG (cv);
   ACE_NOTSUP_RETURN (-1);
# endif /* ACE_HAS_THREADS */
}

         OTHER (please specify)?

     SYNOPSIS:

Test apps compiled against the ACED.DLL run without problems.
Compiling and linking against Unicode ACEUD.DLL causes a
run-time crash.


     DESCRIPTION:

After modifying test apps Task_Test and SOCK_Test to use the
Unicode DLL by changing aced.dll to aceud.dll in the link line,
and adding UNICODE to the preprocessor defines, the app crashes
immediately.


     REPEAT BY:

Under Windows98, compile and link any app using the Unicode
ACEUD.DLL and defining UNICODE as a preprocessor.


     SAMPLE FIX/WORKAROUND:

None.

     -----------------------------_____--__------------------------------
    Jonathan Lindo               / /   \/ /       Muse Communications Corp
    Software Developer       ___/ /   \/ /___                San Mateo, CA
     -----------------------/____/____/_____/----------------------------

Have fun with these links.
Bye.