[Ace-users] [ace-users] [usage question] ACE_Log_Msg / ACE_Log_Record - no allocator
shuston at riverace.com
Tue Nov 27 15:32:50 CST 2007
> First I'd like to thank you for your prompt reply!
> Second, I'd like to apologize for not using the the PRF (I
> thought it is
> not necessary as it was a usage question). Please find it at
> the end of my e-mail.
> I know now that each thread has its own ACE_Log_Msg instance kept in
> TSS. Thanks for pointing this out!
> But, inside the method:
> > ssize_t
> > ACE_Log_Msg::log (const ACE_TCHAR *format_str,
> > ACE_Log_Priority log_priority,
> > va_list argp)
> an ACE_Log_Record is instantiated on the stack for which the
> used allocates 'another' 4 KB of data. The ACE_Log_Msg
> internal buffer
> is afterwards copied ( ACE_OS::strcpy) in the internal buffer of
Right... The ACE_Log_Record here used to have it's data as a member
array, and so was allocated off the stack. This was changed, from what
I can see, at:
Tue Mar 28 21:30:01 UTC 2006 jiang,shanshan
<shanshan.jiang at vanderbilt.edu>
Updated these files to solve the stack overflow problem in
and ACE_Log_Record. Moves buffers that can be large in stack
Thanks to qwerty <qwerty0987654321 at mail dot ru> for
suggesting the fix to this problem.
> I made a simple test program, ran 'gdb' on it and found that
> each time
> this function is invoked, the ACE_Log_Record's constructor
> gets called
> and its underlying data is allocated at a different address
> (to try to
> rule out some overloaded 'operator new' I couldn't identify).
> Please tell me if there is something I missed. Thank you!
Nope, you got it right, but the above work to remove the MAXLOGMSGLEN
size restriction could have been done much better to avoid the
every-time alloc/free. I believe this can be done in a much more
efficient manner. One possible idea is to replace the msg_ array in
ACE_Log_Msg with a ACE_Log_Record, but I haven't traced all the
possibilities out to see if this is a good solution. If you can work
out the details of this, that would be great. If you don't have
time/energy to do this, please record this info in Bugzilla or
consider partnering with someone who can analyze the situation and
develop a good fix for it.
Thanks very much for raising this and analyzing the source of the
excessive memory allocations.
Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
> >> On my understanding each time you log something using ACE_Log_Msg
> >> another ACE_Log_Record is created which in turn creates
> its underlying
> >> data (4 KB) on the heap. This can happen very often and may have
> >> negative impact on the overall performance of the application.
> > No, that's incorrect. the 4 KB of data is allocated using
> > thread-specific storage (see the discuss in the POSA2 book at
> > www.cs.wustl.edu/~schmidt/POSA/POSA2/), so the 4 KB is
> allocated only
> > once for each thread.
> >> Is there a way to control the allocation of ACE_Log_Record
> data without
> >> overloading the global new operator?
> > No, but this shouldn't be necessary, as per the discussion above.
> > Thanks,
> > Doug
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
More information about the Ace-users