[ 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::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::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 with 8 threads, 100000 iterations each > # CLAUSE: lib.locale.messages > # INFO (S1) (3 lines): > # TEXT: exercising std::messages > # 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 > __rw_get_facet_by_id__4__rwFRCQ2_3std6localeRCQ2_4__rw13__rw_facet_idPCQ2_3std7codecvtXTcTcTPc_@AF18_13() 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(const std::messages&,int,int,int,const std::basic_string,std::allocator >&)(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.