Some addition info:
1) Such segfault is when OO builded by gcc 4.3.3, on gcc 4.3.2 and early all ok.
2) Such segaults is exist on OO 2.4.1/2.4.2 on all forks (go-oo/infra/etc)
3) Such segfaults is exists on debian/gentoo at least.

Taking a first look ...

And how long is "Taking a first look ..." procedure?

I need to find somebody who can take a look at this ...

Reassigning to the porting project ...

What happens on "all forks" I guess is a problem of those forks. But as you
correctly point out this does not seem to be a "forking" problem but rather a
compiler optimization issue. I think sb would be the best to look into this.

@yarodin:  For one, is this still reproducible with OOo 3.0.1 or recent OOO310
(heading towards OOo 3.1) or DEV300 (heading towards OOo 3.2) snapshots?  (If
not, chances are low anybody will want to invest time into this...)  For
another, I would at least need a stack trace (with symbols; no stripped
libraries) to say anything about this issue.  I have recently done builds of
(CWS sb107 based on) DEV300m42 with a GCC 4.3.3 tool chain and run those OOo
instances on a Debian unstable box without encountering any such SEGVs, so
cannot reproduce this.

@sb:
> For one, is this still reproducible with OOo 3.0.1 or recent OOO310 (heading
towards OOo 3.1) or DEV300 (heading towards OOo 3.2) snapshots? 

It reproducible with <3.0.1 only - 2.4.2,2.4.1

> For another, I would at least need a stack trace (with symbols; no stripped
libraries) to say anything about this issue. 


[New Thread 0xb600d920 (LWP 20374)]
[New Thread 0xb5fecb90 (LWP 20379)]
[New Thread 0xb28d9b90 (LWP 20382)]
[New Thread 0xb20c8b90 (LWP 20383)]
[New Thread 0xb16d9b90 (LWP 20384)]
[New Thread 0xaf56eb90 (LWP 20388)]
[New Thread 0xae9acb90 (LWP 20391)]
[Thread 0xae9acb90 (LWP 20391) exited]
[New Thread 0xae9acb90 (LWP 20400)]
[Thread 0xae9acb90 (LWP 20400) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb600d920 (LWP 20374)]
rtl_uString_getToken (ppThis=0xbfe92e44, pStr=0x0, nToken=0, cTok=32, nIndex=0)
at strtmpl.c:1527
1527    strtmpl.c: No such file or directory.
        in strtmpl.c
(gdb) bt
#0  rtl_uString_getToken (ppThis=0xbfe92e44, pStr=0x0, nToken=0, cTok=32,
nIndex=0) at strtmpl.c:1527
#1  0xb76a8ce3 in comphelper::DocumentInfo::getDocumentTitle
(_rxDocument=@0xbfe92fec)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx:1117
#2  0xb014c869 in SvxConfigPage::Reset (this=0xb5671c08) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/svx/source/dialog/cfg.cxx:1843
#3  0xb6fcc40b in SfxTabDialog::ActivatePageHdl (this=0xacd3d20c,
pTabCtrl=0xacd3d358)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/sfx2/source/dialog/tabdlg.cxx:1440
#4  0xb6fccb81 in SfxTabDialog::Start_Impl (this=0xacd3d20c) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/sfx2/source/dialog/tabdlg.cxx:833
#5  0xb6fccef8 in SfxTabDialog::Execute (this=0xacd3d20c) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/sfx2/source/dialog/tabdlg.cxx:703
#6  0xac5edfa7 in AbstractTabDialog_Impl::Execute (this=0xb171ceac) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/svx/source/dialog/dlgfact.cxx:127
#7  0xb6d82b61 in SfxApplication::MiscExec_Impl (this=0xb1872f18, rReq=@0xb16ff758)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/sfx2/source/appl/appserv.cxx:361
#8  0xb6f13f5c in SfxDispatcher::Call_Impl (this=0xad444228, rShell=@0xb1872f18,
rSlot=@0xb706e448, rReq=@0xb16ff758, bRecord=1 '\001') at
../../inc/sfx2/shell.hxx:226
#9  0xb6f1466e in SfxDispatcher::PostMsgHandler (this=0xad444228, pReq=0xb16ff758)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/sfx2/source/control/dispatch.cxx:1643
#10 0xb6f42f99 in SfxHintPoster::Event (this=0x0, pPostedHint=0xb16ff758)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/tools/link.hxx:158
#11 0xb6f42f39 in SfxHintPoster::LinkStubDoEvent_Impl (pThis=0xb0921df0,
pCaller=0xb16ff758)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/sfx2/source/notify/hintpost.cxx:88
#12 0xb7f898ed in ImplWindowFrameProc (pWindow=0xb1737a34, nEvent=<value
optimized out>, pEvent=0xad28db30)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/tools/link.hxx:158
#13 0xb49a8cb7 in SalDisplay::DispatchInternalEvent (this=0xb5ff3c08) at
../../../inc/vcl/salframe.hxx:304
#14 0xb49a9316 in SalX11Display::Yield (this=0xb5ff3c08) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/unx/source/app/saldisp.cxx:2306
#15 0xb49ad59e in DisplayYield (pDisplay=0xb5ff3c08) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/unx/source/app/saldisp.cxx:691
#16 0xb49a581b in SalXLib::Yield (this=0xb489a008, bWait=true,
bHandleAllCurrentEvents=false)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/unx/source/app/saldata.cxx:642
#17 0xb49b4ac8 in X11SalInstance::Yield (this=0xb5ff98f0, bWait=false,
bHandleAllCurrentEvents=<value optimized out>)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/unx/source/app/salinst.cxx:287
#18 0xb7d8ca49 in Application::Yield (bAllEvents=false) at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/source/app/svapp.cxx:562
#19 0xb7d8cacc in Application::Execute () at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/source/app/svapp.cxx:521
#20 0x0807447e in desktop::Desktop::Main ()
#21 0xb7d914f8 in ImplSVMain () at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/source/app/svmain.cxx:259
#22 0xb7d91595 in SVMain () at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/vcl/source/app/svmain.cxx:300
#23 0x08065af9 in main ()

This bug was the cause of e.g.:

http://bugs.debian.org/513743
http://bugs.debian.org/513931
http://bugs.debian.org/513482

@yarodin:  Please use gdb to print the content of *sTitle before and after
execution of OSL_VERIFY(...) at l. 108 of
comphelper/source/misc/documentinfo.cxx:1.2.

sb@: Structure has no component named operator*
before and after

sb@:
(gdb) p sTitle
$5 = {pData = 0xbffce134}
(gdb) whatis $5
type = rtl::OUString

@yarodin:  You mean, sTitle.pData = 0xbffce134 before and after l. 108?  In the
bt at <#desc9>, pStr=0x0 in frame #0 should be sTitle.pData from frame #1, so my
guess was that >>= at l. 108 for some reason sets sTitle.pData to zero.  Guess
appears to be wrong, though.  I think you need to look at the instruction level
to find out why rtl_uString_getToken (called from within
rtl::OUString::getToken) is called with a second argument of zero during the
call of sTitle.getToken(...) at l. 111 when sTitle.pData is not zero.

sb@:
>You mean, sTitle.pData = 0xbffce134 before and after l. 108? 
yes
> I think you need to look at the instruction level to find out why
rtl_uString_getToken (called from within
> rtl::OUString::getToken) is called with a second argument of zero during the
> call of sTitle.getToken(...) at l. 111 when sTitle.pData is not zero.
I can't, because segfault is before l.111 on l. 108
Breakpoint 3, comphelper::DocumentInfo::getDocumentTitle (_rxDocument=@0xbfadc43c)
    at
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/comphelper/source/misc/documentinfo.cxx:108
108     in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/comphelper/source/misc/documentinfo.cxx
(gdb) p sTitle
$53 = {pData = 0xbfadc444}
(gdb) p sTitle.pData
$54 = (rtl_uString *) 0xbfadc444
(gdb) n
506    
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx:
No such file or directory.
        in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx
(gdb) p sTitle.pData
$55 = (rtl_uString *) 0xbfadc444
(gdb) n
270    
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx:
No such file or directory.
        in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx
(gdb) p sTitle.pData
$56 = (rtl_uString *) 0xbfadc444
(gdb) n
118    
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx:
No such file or directory.
        in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/com/sun/star/uno/Any.hxx
(gdb) p sTitle.pData
$57 = (rtl_uString *) 0xbfadc444
(gdb) n
1117   
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx:
No such file or directory.
        in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx
(gdb) p sTitle.pData
$58 = (rtl_uString *) 0xbfadc444
(gdb) n
1116    in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx
(gdb) p sTitle.pData
$59 = (rtl_uString *) 0xbfadc444
(gdb) n
1117    in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/solver/680/unxlngi6.pro/inc/rtl/ustring.hxx
(gdb) p sTitle.pData
$60 = (rtl_uString *) 0xbfadc444
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
rtl_uString_getToken (ppThis=0xbfadc294, pStr=0x0, nToken=0, cTok=32, nIndex=0)
at strtmpl.c:1527
1527    strtmpl.c: No such file or directory.
        in strtmpl.c
Current language:  auto; currently c

sb@: But you right, something wrong at         in
/var/tmp/portage/app-office/openoffice-infra-2.4.2/work/OOH680_m18/comphelper/source/misc/documentinfo.cxx
(gdb) p sTitlePropName
$1 = {pData = 0xac75a64c}
(gdb) p sTitlePropName.pData
$2 = (rtl_uString *) 0xac75a64c
(gdb) ptype rtl_uString
type = struct _rtl_uString {
    oslInterlockedCount refCount;
    sal_Int32 length;
    sal_Unicode buffer[1];
}
(gdb) p (char) sTitlePropName.pData.buffer[0]
$3 = 84 'T'
(gdb) p (char) sTitlePropName.pData.buffer[1]
$4 = 105 'i'
(gdb) p (char) sTitlePropName.pData.buffer[2]
$5 = 116 't'
(gdb) p (char) sTitlePropName.pData.buffer[3]
$6 = 108 'l'
(gdb) p (char) sTitlePropName.pData.buffer[4]
$7 = 101 'e'
(gdb) p (char) sTitlePropName.pData.buffer[5]
$8 = 0 '\0'
(gdb) p sTitlePropName.pData.length
$9 = 5
(gdb) p sTitle.pData.length
$10 = -1389218984
(gdb) p sTitle
$11 = {pData = 0xbfe8d744}
(gdb) p sTitle.pData
$12 = (rtl_uString *) 0xbfe8d744

sorry, something wrong at l.108
OSL_VERIFY( xFrameProps->getPropertyValue( sTitlePropName ) >>= sTitle );

@yarodin:
- "I can't, because segfault is before l.111 on l. 108":  I am pretty sure the
failing call to rtl_uString_getToken stems from l. 111.  Maybe code optimization
fools the debugger here.
- "$10 = -1389218984":  That value of sTitle.pData.length is sure strange, but
need not be the real problem.  If the compiler knows that sTitle.pData.length
cannot yet have been used at that point, it need not yet have initialized it.
As I already wrote, "I think you need to look at the [assembler] instruction
level to find out [more]."

sb@: sorry, but if I could "look at the [assembler] instruction
level to find out [more]" to find cross version compilator problem i would not
have written this bug report.

@yarodin:  Understood.  However, as I wrote, I cannot easily reproduce this at
the moment (I even tried replacing comphelper/source/misc/documentinfo.cxx with
the OOH680m18 comphelper/source/misc/documentinfo.cxx in a DEV300m42 GCC 4.3.3
build, but still had no problems).  I will see if I can find out sometime later
whether there is indeed a problem with GCC 4.3.3 (that happens to hit us on
OOH680m18 but could potentially also hit us on recent DEV300).

Reset assigne to the default "issues@openoffice.apache.org".