[
https://issues.apache.org/jira/browse/STDCXX-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591504#action_12591504
]
vitek edited comment on STDCXX-845 at 4/22/08 6:27 PM:
--------------------------------------------------------------
One other issue that I see is that the {{\_STD::messages<T>::do_get()}} method
might actually call {{\_\_rw_manage_cat_data()}} up to three times to search
the cache. Since each search involves a mutex lock, there are going to be some
wasted cycles. It would be nice to reduce this to one search. Perhaps the
{{_RW::\_\_rw_get_message()}} function could be changed to fill in a pointer to
the {{\_RW::\_\_rw_locale}} that is held by the {{\_STD::locale}} that is kept
in the cache and the {{_RW::\_\_rw_get_locale()}} function could be removed.
So one way to fix this problem would be for the {{\_\_rw_get_locale()}}
function to return the {{\_RW::\_\_rw_locale*}} that is held internally by the
{{\_STD::locale}} instance or for {{\_\_rw_open_cat_data}} to cache the body
pointer directly. This would work, except that we'd have to provide an internal
implementation of {{\_STD::use_facet()}} that would take
{{\_RW::\_\_rw_locale*}}s so we could avoid creating additinal temporaries and
doing unnecessary reference counting.
One last thing I thought I'd mention. The {{\_\_rw_manage_cat_data()}} function
does something that I would normally try to avoid. In order to avoid doing
unnecessary reference counting, calling the {{\_STD::locale}} copy constructor
and destructor, and duplicating the code for deallocating the locale body, it
uses {{memcpy()}} to copy buffers that contain {{\_STD::locale}} objects. It
also uses placement new and explicitly calls the destructor of the
{{\_STD::locale}} class when inserting and removing cache entries. While I'm
certain that this is all fine, it just seems dirty to me.
was (Author: vitek):
One other issue that I see is that the {{_STD::messages<T>::do_get()}}
method might actually call {{\_\_rw_manage_cat_data()}} up to three times to
search the cache. Since each search involves a mutex lock, there are going to
be some wasted cycles. It would be nice to reduce this to one search. Perhaps
the {{_RW::__rw_get_message()}} function could be changed to fill in a pointer
to the {{_RW::\_\_rw_locale}} that is held by the {{_STD::locale}} that is kept
in the cache and the {{_RW::\_\_rw_get_locale()}} function could be removed.
So one way to fix this problem would be for the {{\_\_rw_get_locale()}}
function to return the {{_RW::\_\_rw_locale*}} that is held internally by the
{{_STD::locale}} instance or for {{\_\_rw_open_cat_data}} to cache the body
pointer directly. This would work, except that we'd have to provide an internal
implementation of {{_STD::use_facet()}} that would take
{{_RW::\_\_rw_locale*}}s so we could avoid creating additinal temporaries and
doing unnecessary reference counting.
One last thing I thought I'd mention. The {{\_\_rw_manage_cat_data()}} function
does something that I would normally try to avoid. In order to avoid doing
unnecessary reference counting, calling the {{_STD::locale}} copy constructor
and destructor, and duplicating the code for deallocating the locale body, it
uses {{memcpy()}} to copy buffers that contain {{_STD::locale}} objects. It
also uses placement new and explicitly calls the destructor of the
{{_STD::locale}} class when inserting and removing cache entries. While I'm
certain that this is all fine, it just seems dirty to me.
> [XLC++ 7,8,9] SEGV in 22.locale.messages.mt
> -------------------------------------------
>
> Key: STDCXX-845
> URL: https://issues.apache.org/jira/browse/STDCXX-845
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Locales
> Affects Versions: 4.2.1
> Environment: AIX 5.3 PowerPC IBM XLC++ 9.0
> AIX 5.3 PowerPC IBM XLC++ 8.0
> AIX 5.3 PowerPC IBM XLC++ 7.0
> Reporter: Travis Vitek
> Fix For: 4.2.1
>
> Original Estimate: 4h
> Time Spent: 4h
> Remaining Estimate: 4h
>
> On AIX, when compiled with XLC++ the test 22.locale.messages.mt fails with
> {{SIGSEGV}} or {{SIGABRT}}.
> {{SIGSEGV}} on XLC++ 7.0 for 12a, 12d
> {{SIGABRT}} on XLC++ 7.0 for 15a, 15s, 15S
> {{SIGSEGV}} on XLC++ 8.0 for 12a, 12d, 12D, 15a, 15A
> {{SIGABRT}} on XLC++ 8.0 for 15S
> {{SIGSEGV}} on XLC++ 9.0 for 12a, 15a, 15A
> {{SIGABRT}} on XLC++ 9.0 for 15s
> Here is the output for a 12S build...
> {noformat}
> $ dbx 22.locale.messages.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc/LP64 running aix-5.3
> # FILE: 22.locale.messages.mt.cpp
> # COMPILED: Apr 9 2008, 16:38:10
> # COMMENT: thread safety
> ############################################################
> # CLAUSE: lib.locale.messages
> # NOTE (S2) (5 lines):
> # TEXT: executing "gencat rwstdmessages.cat rwstdmessages.msg"
> # CLAUSE: lib.locale.messages
> # FILE: process.cpp
> # LINE: 279
> # INFO (S1) (3 lines):
> # TEXT: testing std::messages<charT> with 8 threads, 100000 iterations each
> # CLAUSE: lib.locale.messages
> # INFO (S1) (3 lines):
> # TEXT: exercising std::messages<char>
> # CLAUSE: lib.locale.messages
> Segmentation fault (core dumped)
> $ dbx 22.locale.messages.mt
> Type 'help' for help.
> [using memory image in core]
> reading symbolic information ...
> Segmentation fault in strchr.strchr at 0x900000000048ec0 ($t2)
> 0x900000000048ec0 (strchr+0x140) 8d230001 lbzu r9,0x1(r3)
> (dbx) where
> strchr.strchr() at 0x900000000048ec0
> _C_get_std_facet(__rw::__rw_facet::_C_facet_type,__rw::__rw_facet*(*)(unsigned
> long,const char*)) const() at 0x100027970
> [EMAIL PROTECTED]() at 0x100070e54
> do_get__Q2_3std8messagesXTc_CFiN21RCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__()
> at 0x1000373ec
> get__Q2_3std8messagesXTc_CFiN21RCQ2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__()
> at 0x100037178
> 22.locale.messages.mt.void test_get<char>(const
> std::messages<char>&,int,int,int,const
> std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)(msgs =
> &(...), cat = 0, set = 4, msgid = 4, dflt = &(...)), line 153 in
> "22.locale.messages.mt.cpp"
> unnamed block in thread_func(void*)( = 0x0ffffffffffff2e0), line 189 in
> "22.locale.messages.mt.cpp"
> thread_func(void*)( = 0x0ffffffffffff2e0), line 189 in
> "22.locale.messages.mt.cpp"
> (dbx) quit
> {noformat}
> This is a new test for 4.2.1, so it is a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
