set version: Current
Duplicate to internal task 146863 submitted by crashreporter, will close
internal task.

cd: Accepted and started. Can be reproduced on some machines.

cd->mmeeks: Looks like a problem related to your changes made in CWS
salstrintern and ::rtl::OUString. See the stack below:

#0  0x05ef535d in rtl_locale_equals () from /opt/staroffice8/program/libuno_sal.so.3
#1  0x05ef8267 in rtl_ustr_ascii_shortenedCompareIgnoreAsciiCase_WithLength ()
   from /opt/staroffice8/program/libuno_sal.so.3
#2  0x015a8532 in rtl::OUString::intern (this=0xbfaf6408)
    at /so/ws/SRC680/unxlngi6.pro/inc.m208/rtl/ustring.hxx:1104
#3  0x015b338b in ExtractToolbarParameters (rProp=
      {_pSequence = 0xb708236c, static s_pType = 0xb66743dc},
rCommandURL=@0xbfaf6408, 
    rLabel=@0xbfaf63f8, rHelpURL=@0xbfaf63e8, rWidth=@0xbfaf63e2,
rVisible=@0xbfaf63e7, 
    rType=@0xbfaf63e4)
    at /export/home/cd100003/framework/source/xml/toolboxdocumenthandler.cxx:127
#4  0x015b8d0f in framework::OWriteToolBoxDocumentHandler::WriteToolBoxDocument (
    this=0xbfaf64e8)
    at /export/home/cd100003/framework/source/xml/toolboxdocumenthandler.cxx:764
#5  0x015b3176 in framework::ToolBoxConfiguration::StoreToolBox
(xServiceFactory=@0xb6412df8, 
    rOutputStream=@0xbfaf65c8, rToolbarConfiguration=@0xb599ca0c)
    at /export/home/cd100003/framework/source/xml/toolboxconfiguration.cxx:177
#6  0x04d2a640 in
framework::ModuleUIConfigurationManager::impl_storeElementTypeData (
    this=0xb6412d4c, xStorage=
        {<com::sun::star::uno::BaseReference> = {_pInterface = 0xb59dd568}, <No
data fields>}, rElementType=@0xb646ba78, bResetModifyState=true)
    at
/so/ws/SRC680/src/framework/source/uiconfiguration/moduleuiconfigurationmanager.cxx:535
#7  0x04d2abd5 in framework::ModuleUIConfigurationManager::store (this=0xb6412d4c)
    at /so/ws/SRC680/unxlngi6.pro/inc/com/sun/star/uno/Reference.hxx:129
#8  0x04d7d591 in framework::ToolBarManager::MenuSelect (this=0xb59d7110,
pMenu=0xb70ab648)
    at /so/ws/SRC680/unxlngi6.pro/inc/com/sun/star/uno/Reference.h:339
#9  0x04d7d87e in framework::ToolBarManager::LinkStubMenuSelect (pThis=0xb59d7110, 
    pCaller=0xb70ab648)
    at /so/ws/SRC680/src/framework/source/uielement/toolbarmanager.cxx:1739
#10 0x00744091 in Menu::Select () from /opt/staroffice8/program/libvcl680li.so
#11 0x007501df in PopupMenu::EndExecute () from
/opt/staroffice8/program/libvcl680li.so
#12 0x00751c13 in PopupMenu::Execute () from /opt/staroffice8/program/libvcl680li.so
#13 0x0077c148 in ToolBox::GetMenuButtonHdl () from
/opt/staroffice8/program/libvcl680li.so
#14 0x0077c251 in ToolBox::GetMenuButtonHdl () from
/opt/staroffice8/program/libvcl680li.so
#15 0x0077c264 in ToolBox::GetMenuButtonHdl () from
/opt/staroffice8/program/libvcl680li.so
#16 0x0079ad76 in Window::doLazyDelete () from
/opt/staroffice8/program/libvcl680li.so
#17 0x07267e76 in SalDisplay::DispatchInternalEvent ()
   from /opt/staroffice8/program/libvclplug_gen680li.so
#18 0x053488f5 in ?? () from /opt/staroffice8/program/libvclplug_gtk680li.so
#19 0xb7f46008 in ?? ()
#20 0xb7f42080 in ?? ()
#21 0xb7f671a8 in ?? ()
#22 0xb7f671a8 in ?? ()
#23 0x0127e1e4 in ?? () from /lib/libglib-2.0.so.0
#24 0x003b27c0 in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0
#25 0x0534891f in ?? () from /opt/staroffice8/program/libvclplug_gtk680li.so
#26 0xb7f5f908 in ?? ()
#27 0xbfaf6c8c in ?? ()
#28 0x0120a6e1 in g_source_is_destroyed () from /lib/libglib-2.0.so.0
#29 0x0120a6e1 in g_source_is_destroyed () from /lib/libglib-2.0.so.0
#30 0x0120c442 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#31 0x0120f41f in g_main_context_check () from /lib/libglib-2.0.so.0
#32 0x0120f985 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#33 0x05347e40 in ?? () from /opt/staroffice8/program/libvclplug_gtk680li.so
#34 0x00000000 in ?? ()

Hi Carsten - interestingly I can't repeat this with OO.o 2.2 and the
salstrintern CWS, which is strange. Do the rtl::OUString unit tests run for you
? cf. sal/qa/rtl_strings/rtl_OUString.cxx

I'll try to download an m208 binary and plug in a self-built m208 sal to see if
I can reproduce here; it -sounds- like some daft memory corruption though; it'd
be great to get some sal symbols there [ if possible ].

cd->mmeeks: Hi Michael, here is a better stack with sal debug.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1105199712 (LWP 13755)]
0x40b4c732 in rtl_str_hash_intern (pHash=0x4405edb0, pString=0x40b759f8,
can_return=0)
    at /export/home/cd100003/sal/rtl/source/hash.cxx:74
74          pString->refCount |= SAL_STRING_INTERN_FLAG;
Current language:  auto; currently c++
(gdb) where
#0  0x40b4c732 in rtl_str_hash_intern (pHash=0x4405edb0, pString=0x40b759f8,
can_return=0)
    at /export/home/cd100003/sal/rtl/source/hash.cxx:74
#1  0x40b536aa in rtl_ustring_intern_internal (newStr=0xbfffdc44, str=0x40b759f8,
    can_return=CANNOT_RETURN) at ustring.c:694
#2  0x40b53753 in rtl_uString_intern (newStr=0xbfffdc44, str=0x40b759f8) at
ustring.c:719
#3  0x450c0532 in rtl::OUString::intern (this=0xbfffdd58) at ustring.hxx:1104
#4  0x450cb38b in ExtractToolbarParameters (rProp={_pSequence = 0x45c928ec,
static s_pType = 0x0},
    rCommandURL=@0xbfffdd58, rLabel=@0xbfffdd48, rHelpURL=@0xbfffdd38,
rWidth=@0xbfffdd32,
    rVisible=@0xbfffdd37, rType=@0xbfffdd34)
    at /export/home/cd100003/framework/source/xml/toolboxdocumenthandler.cxx:127
#5  0x450d0d0f in framework::OWriteToolBoxDocumentHandler::WriteToolBoxDocument
(this=0xbfffde38)
    at /export/home/cd100003/framework/source/xml/toolboxdocumenthandler.cxx:764
#6  0x450cb176 in framework::ToolBoxConfiguration::StoreToolBox
(xServiceFactory=@0x457f5ed8,
    rOutputStream=@0xbfffdf18, rToolbarConfiguration=@0x45b5912c)
    at /export/home/cd100003/framework/source/xml/toolboxconfiguration.cxx:177
#7  0x45431640 in
framework::ModuleUIConfigurationManager::impl_storeElementTypeData (
    this=0x457f5e2c, xStorage=
        {<com::sun::star::uno::BaseReference> = {_pInterface = 0x45674798}, <No
data fields>},
    rElementType=@0x455e5178, bResetModifyState=true)
    at
/so/ws/SRC680/src/framework/source/uiconfiguration/moduleuiconfigurationmanager.cxx:535
#8  0x45431bd5 in framework::ModuleUIConfigurationManager::store (this=0x457f5e2c)
    at Reference.hxx:129
#9  0x45484591 in framework::ToolBarManager::MenuSelect (this=0x45b438f0,
pMenu=0x47116f0c)
    at Reference.h:339
#10 0x4548487e in framework::ToolBarManager::LinkStubMenuSelect
(pThis=0x45b438f0, pCaller=0x47116f0c)
    at /so/ws/SRC680/src/framework/source/uielement/toolbarmanager.cxx:1739
#11 0x40213091 in Menu::Select () from
/export/home/cd100003/ooo23_m208/program/libvcl680li.so
#12 0x4021f1df in PopupMenu::EndExecute ()
   from /export/home/cd100003/ooo23_m208/program/libvcl680li.so
#13 0x40220c13 in PopupMenu::Execute () from
/export/home/cd100003/ooo23_m208/program/libvcl680li.so
#14 0x4024b148 in ToolBox::GetMenuButtonHdl ()
   from /export/home/cd100003/ooo23_m208/program/libvcl680li.so
#15 0x4024b251 in ToolBox::GetMenuButtonHdl ()
   from /export/home/cd100003/ooo23_m208/program/libvcl680li.so
#16 0x4024b264 in ToolBox::GetMenuButtonHdl ()
   from /export/home/cd100003/ooo23_m208/program/libvcl680li.so
#17 0x40269d76 in Window::doLazyDelete () from
/export/home/cd100003/ooo23_m208/program/libvcl680li.so
#18 0x42d06e76 in SalDisplay::DispatchInternalEvent ()

So, firstly, thanks for the nice trace - most helpful. This is extremely curious
however:

0x40b4c732 in rtl_str_hash_intern (pHash=0x4405edb0, pString=0x40b759f8,
can_return=0)
    at /export/home/cd100003/sal/rtl/source/hash.cxx:74
74          pString->refCount |= SAL_STRING_INTERN_FLAG;
Current language:  auto; currently c++

The code immediately before this is:

    if (!can_return) // branch taken, as above can_return == 0
    {
        rtl_uString *pCopy = NULL;
        rtl_uString_newFromString( &pCopy, pString );
        pString = pCopy;
        if (!pString)
            return NULL;
    }

    pString->refCount |= SAL_STRING_INTERN_FLAG;

So - pString is memory returned from rtl_uString_newFromString - so it seems
rather extraordinary that it would return invalid memory.

On the other hand - it -looks- like the code simply doesn't handle the case 
where we intern ourselves that well:

void SAL_CALL rtl_uString_intern( rtl_uString ** newStr,
                                  rtl_uString  * str)
{
... /* causes problems if *newStr == str */ ...
        if (*newStr)
        {
            rtl_uString_release (*newStr);
            *newStr = NULL;
        }
        rtl_ustring_intern_internal( newStr, str, CANNOT_RETURN );
    }
}

But, oddly that code should never be called; cf. ustring.hxx:

        rtl_uString * pNew = 0;
        rtl_uString_intern( &pNew, pData );

pNew is (in every case here) NULL.

So, in a nut-shell, it's rather unclear how this could happen :-) and/or I'd
love to blame pathalogical heap corruption outside my scope.

so - the (IMHO) unrelated trivial fix is in i#76322# - but still no clue wrt.
this, of course valgrind would most likely find it rather fast.
Failing that, it'd be interesting to examine the contents of the string before /
after the copy.

Hi guys,

took a quick look at this one, removing the "const" from the empty string in
sal/rtl/source/ustring.c actually cures the problem. This "const" become
introduce with SB69 in m206, while salstrintern was based on m202, independently
the CWSs seem to work correctly.

Best fix seems to be to mark the empty string with the SAL_STRING_INTERN_FLAG,
to avoid manipulation of the refcount by the internalization functions.

Adding patch ...

Adjusted prio to 1.

Created attachment 44404 [details]
patch for sal/rtl/source/ustring.c to mark the empty string as INTERN .

Kay - thanks muchly, you rock :-) glad it was a resync problem and not some
twisted design issue.

Added Heiner to CC: .

-> Michael, too much honour, this was simple :-) , looking forward to your
comments in case my threading stuff gets eventually integrated ... :-)

Added me to CC: as well .

cc.

fixed in SRC680 m209

Fix verified for Windows and Linux.

Closing.