<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello all,<br>
<br>
Thanks Steve for your answer!<br>
I am analyzing now the code in order to do the fix and found that
ACE_Log_Msg::msg_off_ member is declared static. I do not think this is
a good idea considering that ACE_Log_Msg class is used from different
threads (it is used unprotected in ACE_Log_Msg::log() method) There is
also some confusion about it in the code: it is used some times 'like'
a non-static member (this->msg_off_) and some times 'like' a static
one (ACE_Log_Msg::msg_off_).<br>
<br>
1. Considering that ACE_Log_Msg is kept in TSS I think it is OK to make
member 'msg_off_' non-static.<br>
2. Proposed fix for the every-time alloc/free (general idea):<br>
<br>
a) use an ACE_Log_Record* instead of ACE_TCHAR* to store the log line;<br>
<br>
b) declare a new constructor for the ACE_Log_Record that takes as input
the size to allocate for the inner buffer (currently all ACE_Log_Record
ctors allocate as many bytes as ACE_Log_Msg needs but we shouldn't hard
code this dependency between Log_Msg and Log_Record, a future change of
either of one will lead to the change of the other one);<br>
<br>
c) allocate the Log_Record once (in the ctor) and delete once (in
destructor)<br>
<br>
Can someone point me to a page describing the process to follow when
posting a fix?<br>
<br>
Best regards,<br>
Bogdan<br>
<br>
<br>
Steve Huston wrote:
<blockquote cite="mid011301c8313d$11871290$6601a8c0@hope" type="cite">
<pre wrap="">Hi Bogdan,
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Thanks!
</pre>
<blockquote type="cite">
<pre wrap="">I know now that each thread has its own ACE_Log_Msg instance kept in
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">TSS. Thanks for pointing this out!
But, inside the method:
</pre>
<blockquote type="cite">
<pre wrap="">ssize_t
ACE_Log_Msg::log (const ACE_TCHAR *format_str,
ACE_Log_Priority log_priority,
va_list argp)
</pre>
</blockquote>
<pre wrap="">an ACE_Log_Record is instantiated on the stack for which the
constructor
used allocates 'another' 4 KB of data. The ACE_Log_Msg
internal buffer
is afterwards copied ( ACE_OS::strcpy) in the internal buffer of
ACE_Log_Record.
</pre>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-rfc2396E" href="mailto:shanshan.jiang@vanderbilt.edu"><shanshan.jiang@vanderbilt.edu></a>
* ace/Log_Msg.{h,cpp}
* ace/Log_Record.{cpp,h,inl}:
Updated these files to solve the stack overflow problem in
ACE_Log_Msg
and ACE_Log_Record. Moves buffers that can be large in stack
in malloced
memory.
Thanks to qwerty <qwerty0987654321 at mail dot ru> for
motivating and
suggesting the fix to this problem.
</pre>
<blockquote type="cite">
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap=""><!---->
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.
Best regards,
-Steve
--
Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
See <a class="moz-txt-link-freetext" href="http://www.riverace.com/training.htm">http://www.riverace.com/training.htm</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On my understanding each time you log something using ACE_Log_Msg
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">another ACE_Log_Record is created which in turn creates
</pre>
</blockquote>
</blockquote>
<pre wrap="">its underlying
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">data (4 KB) on the heap. This can happen very often and may have
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->a
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">negative impact on the overall performance of the application.
</pre>
</blockquote>
<pre wrap="">No, that's incorrect. the 4 KB of data is allocated using
thread-specific storage (see the discuss in the POSA2 book at
<a class="moz-txt-link-abbreviated" href="http://www.cs.wustl.edu/~schmidt/POSA/POSA2/">www.cs.wustl.edu/~schmidt/POSA/POSA2/</a>), so the 4 KB is
</pre>
</blockquote>
<pre wrap="">allocated only
</pre>
<blockquote type="cite">
<pre wrap="">once for each thread.
</pre>
<blockquote type="cite">
<pre wrap="">Is there a way to control the allocation of ACE_Log_Record
</pre>
</blockquote>
</blockquote>
<pre wrap="">data without
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">overloading the global new operator?
</pre>
</blockquote>
<pre wrap="">No, but this shouldn't be necessary, as per the discussion above.
Thanks,
Doug
</pre>
</blockquote>
<pre wrap="">_______________________________________________
ace-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ace-users@mail.cse.wustl.edu">ace-users@mail.cse.wustl.edu</a>
<a class="moz-txt-link-freetext" href="http://mail.cse.wustl.edu/mailman/listinfo/ace-users">http://mail.cse.wustl.edu/mailman/listinfo/ace-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>