Issue 121139

I was unable to replicate the bug on 121139 configurations on the Window 7 platform.  The first time I ran the test configuration it did not crash but when I did click the OK button it did not do anything to Outline Numbering meaning once I clicked the OK button the Outline Numbering dialog box closed and there was no numbering of the outline. So I am assuming that is what you mean by a Crash? I ran the configurations again 

Tools->Outline Numbering
*This time not immediately clicking the OK button but formatting the Outline Numbering. See below:

If you’re wondering why you never got the number of the Headings to show up is because there was no specified formatting of the Paragraph Style and Number in the dialog box. 
Click on the Help button in the Outline Numbering dialog it tells you how to format it. This is from the Help dialog box under Paragraph Style and Number: “Select the paragraph style that you want to assign to the selected outline level. If you click “None”, the selected outline level is not defined.” “Specify the formatting for the outline level.”  
So run configurations again but this time under Number selection click a style of formatting and you will see on your right side of the dialog box a change of formatting in the headings. Thus, you know that you selected an outline and your outline is now defined.

Which revision number has your build? You find the number in Help > About OpenOffice. 

It is not about how to use the dialog (I know it), but it is about a crash. Program shuts done and document recovery dialog opens. And it crashes too, if you have done something in the dialog.

CC myself

I could not to reproduce the crash on Windows 7 (64bit) with revision 1392744 from trunk.

I have made a new build from trunk r1393341. It still crashes. Perhaps your build differs in some aspects from my build. Here is my configure

./configure \
 --with-directx-home="/cygdrive/c/Programme/Microsoft DirectX SDK (March 2009)" \
 --with-cl-home="/cygdrive/c/Programme/Microsoft Visual Studio 9.0/VC" \
 --disable-build-mozilla \
 --disable-activex \
 --with-mozilla-build="/cygdrive/c/mozillabuild" \
 --disable-binfilter \
 --enable-dbgutil \
 --with-asm-home="/cygdrive/c/Programme/Microsoft Visual Studio 9.0/VC/bin" \
 --with-jdk-home="/cygdrive/c/Programme/Java/jdk1.6.0_20" \
 --with-ant-home=/ant \
 --with-mspdb-path="/cygdrive/c/Programme/Microsoft Visual Studio 9.0/Common7/IDE" \
 --without-junit \
 --with-dmake-url="http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2" \
 --enable-pch \
 --without-fonts \
 --with-atl-include-dir="/cygdrive/c/WinDDK/7600.16385.1/inc/atl71" \
 --with-atl-lib-dir="/cygdrive/c/WinDDK/7600.16385.1/lib/ATL/i386" \
 --with-mfc-include-dir="/cygdrive/c/WinDDK/7600.16385.1/inc/mfc42" \
 --with-mfc-lib-dir="/cygdrive/c/WinDDK/7600.16385.1/lib/Mfc/i386" \
 --with-vendor="Regina_debug" \
 --with-build-version="2012_10_03"

Here are the configure options I am using:
--with-ant-home="/cygdrive/c/AOO/ant" \
--with-dmake-path=c:/AOO/sources/devtools/dmake.exe \
--with-external-tar=c:/AOO/sources/ext_sources \
--without-junit \
--enable-pch \
--enable-dbgutil \
--disable-directx \
--disable-atl --disable-activex \
--disable-binfilter \
--enable-presenter-console \
--enable-minimizer \
--enable-wiki-publisher \
--enable-bundled-dictionaries \
--enable-category-b \
--disable-build-mozilla \
--with-mozilla-build=c:/mozilla-build \
--disable-odk \
--disable-binfilter \

Thus, I am building without atl and activex. But these should be not involved in Tools - Outline Numbering

I propose to exchange our installation sets - I will let you know when my installation set is available.
May be it is a Windows XP only problem - let me see, if I have a Windows XP VM available for testing.

I see, that you use "with-external-tar=c:/AOO/sources/ext_sources". Perhaps they are not at the same state as from trunk?

"I propose to exchange our installation sets."
I have never before upload such large file and do not know, if that will work.

(In reply to comment #7)
> I see, that you use "with-external-tar=c:/AOO/sources/ext_sources". Perhaps
> they are not at the same state as from trunk?
> 
The directory is filled and checked by <bootstrap> script. I using this directory for sharing it between my different local environments.


> "I propose to exchange our installation sets."
> I have never before upload such large file and do not know, if that will
> work.
I am uploading to my people.apache.org space.
E.g. you can do by <scp <instset> <yourAccount>@people.apache.org:/<folder in your home directory> - it will take some time. Afterwards you can login into people.apache.org and move the <instset> to folder public_html which have to be in your home directory

My instset of revision 1392744 can be found at people.apache.org/~orw/

My version of revision 1393341 is uploaded too, http://people.apache.org/~regina/

Here at home I have installed it from setup.exe in instsetoo_native\wntmsci12\OpenOffice\msi\install\en-US. The upload is from ..\en-US_download. I hope that makes no difference.

(In reply to comment #10)
> My version of revision 1393341 is uploaded too,
> http://people.apache.org/~regina/
> 
> Here at home I have installed it from setup.exe in
> instsetoo_native\wntmsci12\OpenOffice\msi\install\en-US. The upload is from
> ..\en-US_download. I hope that makes no difference.

This didn't crash here.
Neither the install sets from http://people.apache.org/~arielch/packages/r1391723/win/

(In reply to comment #10)
> My version of revision 1393341 is uploaded too,
> http://people.apache.org/~regina/

This works fine on my Windows 7 machine.

Unfortunately, I have problems to install Regina's and my non-pro build on my Windows XP VM.
I am now creating a pro build of revision 1393341 in order to test it on my Windows XP VM

I have uploaded my pro build to people.apache.org.
I tested it on my Windows XP VM and I could not reproduce the described crash.

Hi, I think I come nearer to the reason. It seems to be connected to the path length.

Installations in
E:\AOOdevTest
C:\Programme\AOOdevTest
E:\SoftwareArchiv\AOOdevTest
work

Installations in
E:\SoftwareArchiv\OOoDownloads\AOO 2012-08-git r1393341 newStepGradients
E:\SoftwareArchiv\OOoDownloads\AOO
crash.

(In reply to comment #14)
> Hi, I think I come nearer to the reason. It seems to be connected to the
> path length.
> 
> Installations in
> E:\AOOdevTest
> C:\Programme\AOOdevTest
> E:\SoftwareArchiv\AOOdevTest
> work
> 
> Installations in
> E:\SoftwareArchiv\OOoDownloads\AOO 2012-08-git r1393341 newStepGradients
> E:\SoftwareArchiv\OOoDownloads\AOO
> crash.

I will check an installation on a "long" directory path.

I could not reproduce the crash on my Windows 7 and my Windows XP VM after installation on a "long" path.

So let us adjourn the bug. I have found a workaround for me.
Because the default path is short enough and you cannot reproduce it, most other users will not notice any problem. And if really someone is affected, shorten the installation path will likely help him as well.

At least not very satisfying, esp. from a developers point of view.

BTW, did you reproduced the crash also with the installation sets which I had provided?

(In reply to comment #18)
> At least not very satisfying, esp. from a developers point of view.
> 
> BTW, did you reproduced the crash also with the installation sets which I
> had provided?

Yes, your installation set crashes here too. I have not tested Ariel's version yet.

Step back. It is not the path length. The crash does not happen with a virgin user profile. I will list all steps I did, not sure whether all of them are needed.

1. Begin test with a new user profile.
2. Start AOO with a new writer document.
3. Tools > Options > Language settings > Languages
4. Enable both "Enable UI elements for East Asian writings" and "Enable UI elements Bi-directional writing".
5. Close dialog and close AOO.
6. Start AOO with a new writer document.
7. Tools > Outline Numbering > Choose a numbering > OK
Crash

(In reply to comment #20)
> Step back. It is not the path length. The crash does not happen with a
> virgin user profile. I will list all steps I did, not sure whether all of
> them are needed.
> 
> 1. Begin test with a new user profile.
> 2. Start AOO with a new writer document.
> 3. Tools > Options > Language settings > Languages
> 4. Enable both "Enable UI elements for East Asian writings" and "Enable UI
> elements Bi-directional writing".
> 5. Close dialog and close AOO.
> 6. Start AOO with a new writer document.
> 7. Tools > Outline Numbering > Choose a numbering > OK
> Crash

I can reproduce on Linux, with these steps. It's not reproducible with 3.4.1
Note that here it crashes when I select the menu item, the dialog is not eve shown at all.

I can confirm that this is not reproducible in 3.4.1 (1372287). I'm using Windows 7.

(In reply to comment #20)
> Step back. It is not the path length. The crash does not happen with a
> virgin user profile. I will list all steps I did, not sure whether all of
> them are needed.
> 
> 1. Begin test with a new user profile.
> 2. Start AOO with a new writer document.
> 3. Tools > Options > Language settings > Languages
> 4. Enable both "Enable UI elements for East Asian writings" and "Enable UI
> elements Bi-directional writing".
> 5. Close dialog and close AOO.
> 6. Start AOO with a new writer document.
> 7. Tools > Outline Numbering > Choose a numbering > OK
> Crash

I am back from vacation.

I performed the above steps in the build which Regina had provided on my Windows 7 (64bit). Unfortunately, it did not crash.

The crash still happens with a debug build of r1403730 on WinXP (32bit).

Using MSVC Express for debugging I get the output
     Unhandled exception at 0x01c7d4fa (cppuhelper3MSC.dll) in soffice.bin: 0xC0000005: Access violation reading location 0x00000001.

and the call stack
        cppuhelper3MSC.dll!osl::Guard<osl::Mutex>::Guard<osl::Mutex>()  + 0xb bytes	C++
 	cppuhelper3MSC.dll!cppu::OInterfaceContainerHelper::removeInterface()  + 0x42 bytes	C++
 	cppuhelper3MSC.dll!cppu::OMultiTypeInterfaceContainerHelper::removeInterface()  + 0x74 bytes	C++
 	vcl.dll!04156609()
 	[Frames below may be incorrect and/or missing, no symbols loaded for vcl.dll]
 	vcl.dll!04156860()
 	vcl.dll!03fe5b12()
 	vcl.dll!0400773c()
 	vcl.dll!03ff0c0e()
 	swui.dll!0af480fe()
 	swui.dll!0af485a7()
 	sfx.dll!0248453f()
 	tl.dll!01f3f6f0()
 	sal3.dll!_rtl_cache_free()  + 0xc4 bytes	C
 	8b0c428d()

I hope that is useful for someone.

@Regina:
It is great that you can reproduce it.
If you want we can have a "remote pair-debugging" session to find the root cause.
I am currently at the ApacheCon. Thus, I would have time next week.
If you already want to continue, then I propose that you build module sw inclusive debug information (and may be module vcl, too).
I assume that the root cause is in module sw.

Created attachment 79868 [details]
Compare correct and broken list of numbering formats

The only difference in the dialog between not crashing without "Enable UI elements ..." and crashing with enabled "Enable UI elements ..." is the list of numbering formats. So I think, that the bug is somewhere in that area.

When I compare the working list in AOO3.4.1 with the list in the crashing builds, I notice the list is broken. The items are not complete, there are empty places between the separating commas, and some items are totally wrong. I'll attach a screenshot of the lists.

Where do I find this list in the source?

Created attachment 79869 [details]
glibc memory map

Created attachment 79870 [details]
GDB backtrace

(In reply to comment #26)
> Where do I find this list in the source?

Look at attachment 79870 [details] it is rather informative :)

Now I have disabled "Enable UI elements Bi-directional writing" and only enabled "East Asian Writing". Then I use a "circled number" type of numbering. Now AOO does not crash immediately, but when I save the file and reopen it, then AOO crashes on opening. It crashes not only the debug build but a normal "pro" build too. Tested with normal build r1395635 and "non-pro" build r1403730.

There exist same other bug reports with crashes, where "circled numbers" are present: bug 120752, bug 121101, bug 120903.

I am trying hard to reproduce the crashes on my system, but until now I did not succeed.

Thanks to Regina and Ariel for their stack traces.

I will have a deeper look at the changes made since AOO 3.4.1 in order to figure out which change might cause the crashes.

I couldn't reproduce it on Windows with a non-pro build based on rev. 1407421
with only en-US.
On Linux I have en-US + es-ES + de-DE
I'll try to build those languages on Win too

I have found the root cause together with Herbert

I also see missing numbering characters in the number format list, but could not reproduce the described crashes. I observe other crashes by using number formats with missing numbering characters.

I had a look at the changes made to module i18npool.
I found the change of revision 1350317.
Reverting the change brought back the missing numbering characters in the number format list and the crashes I observed at gone.

Together with Herbert I investigated the code and we got it:
- string <newStr> was created by using (damn) function <x_rtl_uString_new_WithLength(...)> which creates a string with reference count 0.
- the changed return statement (revision 1350317) passes over the ownership of string <newStr> without incrementing the reference count.
--> not a good situation having a string with a reference count of 0.

Solution: 
get rid of function <x_rtl_uString_new_WithLength(...)> in favor of <rtl_uString_new_WithLength(...)> and assure that the memory of the string are not leaking.

@Regina, @Ariel:
Can you please give it a try by just reverting change of revision 1350317 in your environment?

(In reply to comment #33)
> @Regina, @Ariel:
> Can you please give it a try by just reverting change of revision 1350317 in
> your environment?

yes, it fixes the crash:

diff --git a/main/i18npool/source/nativenumber/nativenumbersupplier.cxx b/main/i18npool/source/nativenumber/nativenumbersupplier.cxx
index 8bdc86e..f9bae90 100644
--- a/main/i18npool/source/nativenumber/nativenumbersupplier.cxx
+++ b/main/i18npool/source/nativenumber/nativenumbersupplier.cxx
@@ -93,7 +93,7 @@ OUString SAL_CALL AsciiToNativeChar( const OUString& inStr, sal_Int32 startPos,
             if (useOffset)
                 offset[i] = startPos + i;
         }
-        return OUString( newStr, SAL_NO_ACQUIRE);
+        return OUString( newStr->buffer, nCount);
 }
 
 sal_Bool SAL_CALL AsciiToNative_numberMaker(const sal_Unicode *str, sal_Int32 begin, sal_Int32 len,

(In reply to comment #34)
> (In reply to comment #33)
> > @Regina, @Ariel:
> > Can you please give it a try by just reverting change of revision 1350317 in
> > your environment?
> 
> yes, it fixes the crash:
> 

Thanks for the very fast feedback. Such things are motivating me.

Created attachment 79907 [details]
Windows backtrace

I'm not sure what I did, but after restarting AOO, I could reproduce the crash on Windows. Reverting here solved the crash, too (Linux bactrace was of more help, it seems).

Mentioned solution does not seem to be appropriate for a simple fix as the discussion with Herbert and Andre reveals.

Thus, I decided the adjust function <x_rtl_uString_new_WithLength(...)> in order to assure that the reference count is 1. Further usage have to assure that no memory leaks.

As the changes are sensible I will ask for review the code changes.

Created attachment 79908 [details]
patch to clear reference counting and passing ownership in i18nutil and i18npool

please have a look at the proposed patch.

I have build it with your patch for WinXP. The crashes are gone :)
I have tested outline numbering, hard and soft list numbering, number range variable, save and reload.
But I'm not able to review any other aspects.

(In reply to comment #30)
> Now I have disabled "Enable UI elements Bi-directional writing" and only
> enabled "East Asian Writing". Then I use a "circled number" type of
> numbering. Now AOO does not crash immediately, but when I save the file and
> reopen it, then AOO crashes on opening. It crashes not only the debug build
> but a normal "pro" build too. Tested with normal build r1395635 and
> "non-pro" build r1403730.
> 
> There exist same other bug reports with crashes, where "circled numbers" are
> present: bug 120752, bug 121101, bug 120903.

I have checked these issue in my local environment having the attached patch applied. The crashes did not occur anymore.

Does somebody already had a deeper look at the intrinsic patch?

Comment on attachment 79908 [details]
patch to clear reference counting and passing ownership in i18nutil and i18npool

Thanks! As discussed getting rid of these refcount==0 stillborn strings and the adaptions for it solves the problem nicely and in a clean way. And the memory leaks are still plugged.

While cleaning up the comments I'd recommend to replace the strange "The characters of room is not cleared." to something like "the character buffer does not get initalized".

Other than that the x_rtl_uString* header shouldn't stay around for too long. A "private" string with about half a dozen uses only causes confusion, which was especially true when they were created as stillborns. Sorry for having overlooked that strange behaviour in my original change.

patch applied on trunk - revision 1411116 
changed files:
- i18nutil/inc/i18nutil/x_rtl_ustring.h
- i18nutil/source/utility/widthfolding.cxx
- i18npool/source/nativenumber/nativenumbersupplier.cxx
- i18npool/source/characterclassification/cclass_unicode.cxx
- i18npool/source/transliteration/ignoreKiKuFollowedBySa_ja_JP.cxx
- i18npool/source/transliteration/transliteration_Ignore.cxx
- i18npool/source/transliteration/transliteration_Numeric.cxx
- i18npool/source/transliteration/ignoreIterationMark_ja_JP.cxx
- i18npool/source/transliteration/ignoreProlongedSoundMark_ja_JP.cxx
- i18npool/source/transliteration/transliteration_OneToOne.cxx
- i18npool/source/transliteration/transliteration_body.cxx
- i18npool/source/transliteration/ignoreIandEfollowedByYa_ja_JP.cxx
- i18npool/source/textconversion/textconversion_zh.cxx
- i18npool/source/textconversion/textconversion_ko.cxx

Verified on Aoo_Trunk_20121123.1915 Rev.1412533, no crash, this bug is fixed.

close it