[ace-users] ACE_Task_Base: destruction
Aniket Bhat
ACE VERSION: 5.5.6
HOST MACHINE and OPERATING SYSTEM:
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
Linux 2.6.23.17-88.fc7 x86_64 GNU/Linux
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
Linux 2.6.10_mvl401 mips64 (monta vista linux)
COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc 3.4
BUILD METHOD USED: makefile
AREA/CLASS/EXAMPLE AFFECTED: ACE_Task_Base derived object deletion.
DOES THE PROBLEM AFFECT:
COMPILATION? No
LINKING? No
On Unix systems, did you run make realclean first?
EXECUTION? Yes, crash while trying to delete the ACE_Task_Base derived object.
OTHER (please specify)?
SYNOPSIS:
In a multi-threaded application, the application crashes with a SIGSEGV when trying to destruct an object derived
from ACE_Task_Base.
DESCRIPTION: In a multi-threaded application, we spawn a set of active objects (worker threads) each of which has a unique request Id.
The requests are queued in the context of a thread (say thread_id_1) at which point, a class object derived from ACE_Task_Base
is created and pushed into a map of shared pointer to these ACE_Task_Base derived objects keyed off the request Ids.
This task map is maintained to enable a dictionary look up in order to abort worker threads using the deactivate()
method. Each ACE_Task_Base derived object also maintains the request id as a member and is activated with
the THR_JOINABLE flag. When the svc() routine of the worker threads completes, it calls in a delegate D which
marks the request corresponding to the request Id as complete.
In another thread (say thread_id_2) (which itself is a parent ACE_Task_Base active object), the completed requests'
queue (fed by the delegate D) is traversed and the ACE_Task_Base object is deleted by erasing the entry from the map
after calling wait().The wait() returns success and I also see the close() hook being called when the svc() routine
completes. However, the call to delete the ACE_Task_Base derived object causes SIGSEGV.
All the accesses to the task map and queue of completed requests are guarded by suitable ACE_Guard mutexes.
Is it OK to delete the ACE_Task_Base derived object in the context of another thread (thread_id_2) other than the
one which activated the task (thread_id_1)?
SAMPLE FIX/WORKAROUND:
The implementation can possibly be altered to have the object deletion occur in context of same thread
that create and activated it if it makes sense.
Thanks,
Aniket.
Douglas C. Schmidt
Thanks for using the PRF!
>ACE VERSION: 5.5.6
Please upgrade to ACE+TAO+CIAO x.7.4 (i.e., ACE 5.7.4, TAO 1.7.4, and CIAO
0.7.4), which you can download from
http://download.dre.vanderbilt.edu
under the heading: "Latest Micro Release Kit."
The DOC group at Vanderbilt University only provides "best effort"
support for non-sponsors for the latest release, as described in
http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html
Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out
http://www.dre.vanderbilt.edu/support.html
for a list of companies that will provide you with ACE+TAO commercial
support.
In general, this is a bad idea. Please see Chapter 6 of C++NPv2
<wwww.cs.wustl.edu/~schmidt/ACE/book2/> for information on how to
shutdown and delete ACE_Task objects properly.
>SAMPLE FIX/WORKAROUND:
>
>The implementation can possibly be altered to have the object deletion
>occur in context of same thread
>that create and activated it if it makes sense.
That's a good idea.
Thanks,
Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.sc...@vanderbilt.edu
Aniket Bhat
Thanks for the reply. I do understand that its not generally a good idea to construct and activate an active object in context of one thread and destruct it in context of another. Do you see this as possible cause of the SIGSEGV though? I couldn't get any backtrace that would shed some information on why the dtor barfs.
Thanks,
Aniket.
Hi Aniket,
Thanks for using the PRF!
>ACE VERSION: 5.5.6
Please upgrade to ACE+TAO+CIAO x.7.4 (i.e., ACE 5.7.4, TAO 1.7.4, and CIAO
0.7.4), which you can download from
http://download.dre.vanderbilt.edu
under the heading: "Latest Micro Release Kit."
The DOC group at Vanderbilt University only provides "best effort"
support for non-sponsors for the latest release, as described in
http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html
Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out
http://www.dre.vanderbilt.edu/support.html
for a list of companies that will provide you with ACE+TAO commercial
support.
In general, this is a bad idea. Please see Chapter 6 of C++NPv2
<wwww.cs.wustl.edu/~schmidt/ACE/book2/> for information on how to
shutdown and delete ACE_Task objects properly.
>SAMPLE FIX/WORKAROUND:
>
>The implementation can possibly be altered to have the object deletion
>occur in context of same thread
>that create and activated it if it makes sense.
Douglas C. Schmidt
Hi Aniket,
> Thanks for the reply. I do understand that its not generally a good idea to
> construct and activate an active object in context of one thread and destruct
> it in context of another. Do you see this as possible cause of the SIGSEGV
> though? I couldn't get any backtrace that would shed some information on why
> the dtor barfs.
Since you're running on Linux I recommend you crank up valgrind and see
if it can help you pinpoint the source of the problem.
Thanks,
Doug
> Thanks,
> Aniket.
>
> On Fri, Nov 13, 2009 at 10:46 PM, Douglas C. Schmidt <
> sch...@dre.vanderbilt.edu> wrote:
>
> Hi Aniket,
>
> Thanks for using the PRF!
>
> >ACE VERSION: 5.5.6
>
> Please upgrade to ACE+TAO+CIAO x.7.4 (i.e., ACE 5.7.4, TAO 1.7.4, and CIAO
> 0.7.4), which you can download from
>
> http://download.dre.vanderbilt.edu
>
> under the heading: "Latest Micro Release Kit."
>
> The DOC group at Vanderbilt University only provides "best effort"
> support for non-sponsors for the latest release, as described in
>
> http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/
> ACE-bug-process.html
>
> Thus, if you need more "predictable" help for earlier versions of
> ACE+TAO, I recommend that you check out
>
> http://www.dre.vanderbilt.edu/support.html
>
> for a list of companies that will provide you with ACE+TAO commercial
> support.
>
> In general, this is a bad idea. Please see Chapter 6 of C++NPv2
> <wwww.cs.wustl.edu/~schmidt/ACE/book2/> for information on how to
> shutdown and delete ACE_Task objects properly.
>
> >SAMPLE FIX/WORKAROUND:
> >
> >The implementation can possibly be altered to have the object deletion
> >occur in context of same thread
> >that create and activated it if it makes sense.
>
Douglas C. Schmidt
Hi Aniket,
> Thanks for the prompt reply. I have used valgrind before, but unfortunately
> there is no valgrind port available for mips :(.
Since ACE is hardware-agnostic you just need to find an Intel box and
run your app on that.
> I will continue to debug this and change to calling the ctor and dtor
> of the ACE_Task_Base object in the same thread context as a
> work-around.
That sounds like a good plan!
thanks,
Doug
> Best regards,
> Aniket.
>
> On Fri, Nov 13, 2009 at 11:11 PM, Douglas C. Schmidt <
> > In general, this is a bad idea. Please see Chapter 6 of C++NPv2
> > <wwww.cs.wustl.edu/~schmidt/ACE/book2/> for information on how to
> > shutdown and delete ACE_Task objects properly.
> >
> > >SAMPLE FIX/WORKAROUND:
> > >
> > >The implementation can possibly be altered to have the object
> deletion
> > >occur in context of same thread
> > >that create and activated it if it makes sense.
> >