Created attachment 111319 [details]
strace output from ooimpress

opened bland presentation, selected character, then from Format->Character,
pressed font effects tab

Hope this is helpful..

Hmm.. sorry, my comment got lost :(
The attachment above is a strace output for a similar bug.

I think this is the same as described here:

http://lists.debian.org/debian-openoffice/2004/10/msg00000.html

but I don't know how to fix it  (apparently gsfonts are in the
urw-fonts package?)

Created attachment 111588 [details]
backtrace from bugbuddy

This is what bugbuddy gives me when I reproduce the bug.

I can't really tell if I'm seeing the same bug, because I don't have to change
language in Format->Character to crash it. I think it's the same because I used
the same steps to discover it, and when I think about it, the reporter doesn't
use Format->Character to change font or size, only language, just as I do. I
thought it's related to changing language at first, but now I guess it's not.

Created attachment 111589 [details]
backtrace from bugbuddy in case of "Reset" button

This is what bugbuddy logs if I press "Reset" instead of "OK" in the Character
format dialog.

Additional information - I have lots of TTF fonts in the system. I can change
them via the drop-down list from the toolbar and trying different fonts doesn't
fix the "character" dialog crash. I installed all the fonts almost at the same
time as OOo upgrade, so it can be related and I'll try to find out if removing
the fonts will help. Even if it does, it's still a bug in OOo!

After upgrading to kernel-2.6.10-1.770_FC3 and gtk2-2.6.2-1 I can't reproduce
this bug anymore.

At first I tried to upgrade gtk2, found 2.6.4-1 in Rawhide and installed it and
the dependencies (glib2-2.6.3-1 and pango-1.8.0-1) with the latest official FC3
kernel - that didn't help. Then I downgraded everything back to FC3, but
installed kernel-2.6.10-1.770_FC3 from updates/testing - that didn't help
either. Then I upgraded gtk2, glib2 and pango again to the newest Rawhide
versions (newer than yours) and OOo still crashes. Seems to me your system
differs from the time you reported the crash in more pieces than you say.

Now the good news - I removed ~2000 fonts from my font dirs and voila - OOo
stopped crashing. Then I put ~600 of them back in and it started crashing again.
Then I removed them and it didn't crash. URW fonts were still here, so it's not
their fault as someone suggested somewhere (forgive me not even trying to search
- it's 2:20 here). Then I tried to put back in 25 of my fonts and it crashed,
but removing them didn't help. I don't know how did I do it, but it worked few
times in a row and stopped working after only one copy->run
fc-cache->remove->run fc-cache. Then I tried removing every font I could find
(including URW ones) and it didn't help - OOo would crash every time. Now I'm
not so sure if it's even related to fonts.

I also tried running oowriter as root with "clean" home directory and LANG unset
(in case it was related to languages - that was supposed to give me a test run
similar to what people at Red Hat do themselves), but it crashes anyhow just
after hitting "OK" in "Character" dialog with an empty document.

I'm desperate - I can attach to the process when it crashes and executes
bug-buddy, I can show you output of info frame or something, but I can't give
you core file (it would take few hours to upload it on my link). Because of my
link I'm also not willing to recompile OOo from sources or try another version
ATM (oh, and by the way - "congrats" for distributing ~200 MiB of RPM-s where
uncompressed xdelta on its uncompressed cpio contents is ~5 MiB - fortunatelly I
have access to fast link and a DVD burner from time to time).

nah, no need for the core file.  But, could you attach some backtraces to the
issue?  Preferably 2 or more, so we can make sure that its not some random C++
thing.

If you're able to install the debuginfo package (~500MB) that would be great
too, but I'll understand if you don't since its so big :)  If you did, that
would give us line numbers, argument values, and generally more useful backtraces.

Also, if it does end up being some random font, it would be great if you could
send me the font privately (since many fonts are of course not redistributable
publicly) so that I can figure out what's broken with the font and work around
it in OOo.

Thanks!
Dan

I got rid of almost every font I could find (I removed most of the fonts present
in the default install, which made my system look really ugly, not to mention
squares instead of characters in the menu at one point, when I knew I don't want
to go further :)), I also downgraded freetype to FC3 version (I had the same
version, but recompiled with BCI), restarted xfs few times and even rebooted
after all the removals and freetype downgrade - still no luck.

For now I downgraded to openoffice.org-1.1.3-2.5.fc3 because I need to do some
work, but I'll continue to play with crashing 1.1.3-6.5.0 later, after I go and
burn myself RPM-s including the debuginfo one. I will see if 1.1.3-5.5.0 fits on
the same CD-R to find out which version change introduced the behaviour.

Oh, and the backtraces I attached are rather representative (I made that word
up, sorry :)) - sometimes it crashed 2 levels deeper, but still in functions
called from same "suspect" functions. For example, from the backtrace I attached
yesterday:
#7  <signal handler called>
#8  0x02a6e751 in String::Equals () 
   from /usr/lib/ooo-1.1/program/libtl645li.so
#9  0x03a65bba in FontList::Get ()
   from /usr/lib/ooo-1.1/program/libsvt645li.so
And from some other run today:
#7  <signal handler called>
#8  0x060c8b58 in Container::GetObject ()
   from /usr/lib/ooo-1.1/program/libtl645li.so
#9  0x06994440 in FontList::ImplFind ()
   from /usr/lib/ooo-1.1/program/libsvt645li.so
#10 0x0699457b in FontList::ImplFindByName ()
   from /usr/lib/ooo-1.1/program/libsvt645li.so
#11 0x06995b1a in FontList::Get ()
   from /usr/lib/ooo-1.1/program/libsvt645li.so   
I'd say FontList::Get gives corrupted data to its children, and it probably gets
that data from its parent, but I won't speculate and just try to install the
debuginfo package later today. 

Created attachment 111619 [details]
pressing "OK"

I got my 1.1.3-6.5.0 debuginfo package and this is the information gathered by
Bug Buddy. I also tried attaching to the process with gdb (whoah, it takes up
to 550 MiB of "resident" memory!), but I guess I'm not smart enough to figure
how C++ strings work :) Can someone teach me? For example, in frame #9 I tried:

(gdb) print rName
$11 = (const String &) @0xbfe6fd50: {mpData = 0x2c589e0}
(gdb) print *rName->mpData
$13 = {mnRefCount = 22, mnLen = 18, maStr = {78}}
what, no pointer to char *? Stupid language! :)

More backtraces follow as requested

Created attachment 111620 [details]
pressing "OK", take two

Same case - I just open "Character" dialog and press OK. As requested, second
backtrace of second program crash in the same situation.

Created attachment 111621 [details]
pressing "Reset"

Steps to reproduce this one:
1. run oowriter
2. right click on the document
3. select "Character"
(now instead of pressing "OK" I did:)
4. press "Reset" in the dialog, Bug Buddy pops up :)

Created attachment 111622 [details]
changing Typeface to Bold

This time instead of pressing buttons, I tried to change Typeface to "Bold".
After only a short while OOo tries to update the font preview and guess what?
Bug Buddy is greeting me again :) I start to like BB as it likes me apparently
:)

Created attachment 111623 [details]
changing the tab (or so called page)

This is my last backtrace, phew!

I'm looking forward to hearing from you. If you can't provide me with some
instructions to gather more useful data, I can even make an account on my box
for you to debug it (but not necessarily run it with remote X server - my
Internet connection won't take it :)).

Man, are OOo sources HUGE! But I love the style, I use the same style in my
programs, great, feels almost like home, if only it wasn't C++ :)

Breakpoint 1, SvxCharNamePage::FillItemSet_Impl (this=0x34ff9c8, 
    rSet=@0xbfec5d60, eLangGrp=SvxCharNamePage::Western)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svx/source/dialog/chardlg.cxx:1325
1325		FontInfo aInfo( pFontList->Get( rFontName, aStyleBoxText ) );
(gdb) s
FontList::Get (this=0x3cb1660, rName=@0xbfec5cd0, rStyleName=@0xbfec5cc0)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svtools/source/control/ctrltool.cxx:649
649		ImplFontListNameInfo* pData = ImplFindByName( rName );
(gdb) print *(char (*)[100]) rName->mpData->maStr 
$1 = "N\000i\000m\000b\000u\000s\000 \000R\000o\000m\000a\000n\000
\000N\000o\0009\000 \000L\000\000\000 (rest is garbage --Lam)
(gdb) n
650		ImplFontListFontInfo* pFontInfo = NULL;
(gdb) n
651		ImplFontListFontInfo* pFontNameInfo = NULL;
(gdb) 
652		if ( pData )
(gdb) 
671		FontInfo aInfo;

So it didn't find "Nimbus Roman No 9 L" in pFontList - maybe it should?

(gdb) n
672		if ( !pFontInfo )
(gdb) n
674			if ( pFontNameInfo )
(gdb) n
639								{ return rStr1.Equals( rStr2 ); }
(this is string.hxx:639, operator == of class UniString, expanded from line 677:
if ( rStyleName == maNormal ))
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
String::Equals (this=0xbfec5cc0, rStr=@0x3cb1698) at strimp.cxx:1476

(gdb) bt
#0  String::Equals (this=0xbfec5cc0, rStr=@0x3cb1698) at strimp.cxx:1476
#1  0x004abbba in FontList::Get (this=0x3cb1660, rName=@0xbfec5cd0, 
    rStyleName=@0xbfec5cc0) at string.hxx:639

as you can see, gdb won't show us the real guilty line, which is
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svtools/source/control/ctrltool.cxx:677,
but we were smart enough to figure it out anyhow :)

Now, in frame #0 "this" is #1's rStyleName and rStr is maNormal. rStyleName
contains UniString "Regular", but maNormal is some garbage:
(gdb) print rStyleName
$9 = (const String &) @0xbfec5cc0: {mpData = 0x3a717f8}
(gdb) print *(char (*)[100])rStyleName->mpData->maStr
$11 = "R\000e\000g\000u\000l\000a\000r", '\0' <repeats 15 times>, (rest
irrelevant --Lam)
(gdb) print maNormal
$13 = {mpData = 0x2}
(gdb) print maNormal->mpData
$14 = (UniStringData *) 0x2
(gdb) print maNormal->mpData->maStr
Cannot access memory at address 0xa

Now, as I see it, maNormal should be initialized by FontList::FontList
constructor in
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svtools/source/control/ctrltool.cxx:401

Oh, and this time line 649 ran, but not returned anything, other times it
crashed because nCount was some random number like 7667820 or 2097268 (real
values from few of my crashes).

All this leads to a conclusion that this FontList object was never initialized.
Let's see where it's from.

Breakpoint 1, SvxCharNamePage::FillItemSet_Impl (this=0x3396008, 
    rSet=@0xbff9bc40, eLangGrp=SvxCharNamePage::Western)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svx/source/dialog/chardlg.cxx:1320
1320		const FontList* pFontList = GetFontList();
(gdb) s
SvxCharNamePage::GetFontList (this=0x3396008)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svx/source/dialog/chardlg.cxx:856
856	    if ( !m_pImpl->m_pFontList )
(gdb) n
876	    return m_pImpl->m_pFontList;
(gdb) print m_pImpl->m_pFontList->nCount
$1 = 24
okay, now it's 24... kill, run, (breakpoint), step, next, we're in line 876
again and:
(gdb) print m_pImpl->m_pFontList->nCount
$4 = 2097260

so it looks random, but where did it come from?
some of the fields in m_pImpl->m_pFontList look initialized:

(gdb) print *m_pImpl->m_pFontList
$7 = {<List> = {<Container> = {pFirstBlock = 0x1, pCurBlock = 0x15, 
      pLastBlock = 0x690064, nCurIndex = 103, nBlockSize = 105, 
      nInitSize = 116, nReSize = 97, nCount = 2097260}, <No data fields>}, 
  maMapBoth = {mpData = 0x650072}, maMapPrinterOnly = {mpData = 0x640061}, 
  maMapScreenOnly = {mpData = 0x75006f}, maMapSizeNotAvailable = {
    mpData = 0x200074}, maMapStyleNotAvailable = {mpData = 0x680074}, 
  maMapNotAvailable = {mpData = 0x630069}, maLight = {mpData = 0x6b}, 
  maLightItalic = {mpData = 0x2bd3636}, maNormal = {mpData = 0x80000018}, 
  maNormalItalic = {mpData = 0x40}, maBold = {mpData = 0x2ba6950}, 
  maBoldItalic = {mpData = 0x2bab8f0}, maBlack = {mpData = 0x2cb0007}, 
  maBlackItalic = {mpData = 0x2cb7d20}, mpSizeAry = 0x80000030, mpDev = 0x18, 
  mpDev2 = 0x2ba0001}
(gdb) print m_pImpl->m_pFontList->maNormal->mpData->maStr
Cannot access memory at address 0x80000020
(gdb) print m_pImpl->m_pFontList->maLight->mpData->maStr
Cannot access memory at address 0x73
(gdb) print *(char (*)[100]) m_pImpl->m_pFontList->maBold->mpData->maStr
$11 = "d\000i\000g\000i\000t\000a\000l\000
\000r\000e\000a\000d\000o\000u\000t\000 \000t\000h\000i\000c\000k\000\000\000
(digital readout thick, font from Shy Fonts, it's not bold, but it is a real
font :))

Now, back to
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svtools/source/control/ctrltool.cxx:401,
where maNormal should be initialized, I put a breakpoint there, but it was never
(wasn't ever?) called. That's strange, because something initializes maNormal.
Maybe the function has many versions and my breakpoint sticked to only one of
them - I didn't try to find out.

m_pImpl->m_pFontList is set at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svx/source/dialog/chardlg.cxx:1747.
Funny thing is m_pImpl->m_pFontList->maNormal->mpData->maStr is "Regularna"
(polish for "periodic", but I guess the translator didn't know that and thought
"regular" means just it). m_pImpl->m_pFontList->nCount = 1548. I inserted
breakpoints in all the places where m_pImpl->m_pFontList can change, but it's
not changing as a pointer, and the contents change instead, only I don't have
any more patience to track it (or rather, I go to sleep, it's 0:45 AM).

I will work on it some more tomorrow, fear! :)

Today I woke up and started to debug it again, but software watchpoint didn't
give me an answer after 6 hours of program "run" (I'd call it crawl) :) So:

Breakpoint 1, SvxCharNamePage::SetFontList (this=0x4d57620, rItem=@0x1e9fd60)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svx/source/dialog/chardlg.cxx:1747
1747		m_pImpl->m_pFontList = rItem.GetFontList();
(gdb) print m_pImpl->m_pFontList->nCount
$1 = 29   (as you can see, I got rid of most of the fonts --Lam)
(gdb) print &m_pImpl->m_pFontList->nCount
$2 = (ULONG *) 0x4b8b51c
(gdb) watch * (int *) 0x4b8b51c
Hardware watchpoint 4: *(int *) 79213852
(gdb) c
Continuing.
Hardware watchpoint 4: *(int *) 79213852

Old value = 29
New value = 0
0x05d5fe22 in Impl_Font::Impl_Font () at salbtype.hxx:727
(gdb) bt
#0  0x05d5fe22 in Impl_Font::Impl_Font () at salbtype.hxx:727
#1  0x05d5ff32 in Font::MakeUnique (this=0xbfe699f0)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/vcl/source/gdi/font.cxx:149
#2  0x05d6050c in Font::SetName (this=0xbfe699f0, rName=@0x0)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/vcl/source/gdi/font.cxx:279
#3  0x05dbaaa2 in OutputDevice::GetDevFont (this=0x1c7aea8, nDevFont=12)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/vcl/source/gdi/outdev3.cxx:6799
#4  0x0667d625 in FontList::ImplInsertFonts (this=0x21f8b90, 
    pDevice=0x1a363f0, bAll=1 '\001', bInsertData=1 '\001')
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svtools/source/control/ctrltool.cxx:308
#5  0x0667e082 in FontList (this=0x21f8b90, pDevice=0x1a363f0, pDevice2=0x0, 
    bAll=1 '\001')
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/svtools/source/control/ctrltool.cxx:408
#6  0xb44d2ab0 in SwDocShell::UpdateFontList (this=0x1e9fc58)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/sw/source/ui/app/docshini.cxx:602
#7  0xb45638fc in SwEditWin::DataChanged (this=0x8b50b20, rDCEvt=@0xbfe69c50)
    at edtwin.hxx:290
#8  0x05e77d66 in Window::NotifyAllChilds (this=0x8b50b20, rDCEvt=@0xbfe69c50)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/vcl/source/window/window.cxx:5493
#9  0x05e77d7c in Window::NotifyAllChilds (this=0x8b50b20, rDCEvt=@0xbfe69c50)
    at
/usr/src/debug/ooo-build-cvs20050205/build/OOO_1_1_3/vcl/source/window/window.cxx:5498
(and so on --Lam)

Then I pushed c and tried to reproduce the crash, but gdb looped and started to
hog CPU (it's full of such surprises btw).

salbtype.hxx:727 is BitmapPalette::operator!, which isn't called from
Impl_Font::Impl_Font by name, but probably is via some inlines. I will
investigate it later :)

I hope this is valuable, if not, just tell me to shut up :)

No, by all means, it's great.  If everyone went to this effort to help debug the
issue, I'd be out of a job.

*** Bug 150353 has been marked as a duplicate of this bug. ***

I can reproduce this crash again with the following steps:
1. run oowriter
2. go to menu item: Format/Character...
3. press "OK" button

Created attachment 111920 [details]
backtrace

this bug is still present in openoffice.org-1.1.3-9.5.0.fc3.
attaching the backtrace.

*** This bug has been marked as a duplicate of 153209 ***