stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (STDCXX-845) [XLC++ 7,8,9] SEGV in 22.locale.messages.mt
Date Wed, 23 Apr 2008 01:29:22 GMT

    [ 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
> __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<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.


Mime
View raw message