Issue 121139 - Crash in Outline Numbering dialog
Crash in Outline Numbering dialog
Status: CLOSED FIXED
Product: Writer
Classification: Application
Component: formatting
4.0.0-dev
All All
: P2 major (vote)
: 4.0.0
Assigned To: Oliver-Rainer Wittmann
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-29 23:45 UTC by Regina Henschel
Modified: 2012-11-28 08:50 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments
Compare correct and broken list of numbering formats (37.84 KB, image/png)
2012-11-06 21:13 UTC, Regina Henschel
no flags Details
glibc memory map (9.81 KB, text/plain)
2012-11-06 22:47 UTC, Ariel Constenla-Haile
no flags Details
GDB backtrace (7.72 KB, text/plain)
2012-11-06 22:48 UTC, Ariel Constenla-Haile
no flags Details
Windows backtrace (4.49 KB, text/plain)
2012-11-13 13:53 UTC, Ariel Constenla-Haile
no flags Details
patch to clear reference counting and passing ownership in i18nutil and i18npool (16.79 KB, patch)
2012-11-13 16:06 UTC, Oliver-Rainer Wittmann
hdu: review+
Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2012-09-29 23:45:23 UTC
Start a new document in Writer and type something.
Tool > Outline Numbering
Do nothing but click directly on the OK button ==> Crash

I see this defect in r1389055 and r1388589, but not in r1384746.
Comment 1 sandra_lynn_howard 2012-09-30 19:59:15 UTC
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.
Comment 2 Regina Henschel 2012-09-30 20:38:49 UTC
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.
Comment 3 Oliver-Rainer Wittmann 2012-10-02 08:22:37 UTC
CC myself
Comment 4 Oliver-Rainer Wittmann 2012-10-02 15:13:09 UTC
I could not to reproduce the crash on Windows 7 (64bit) with revision 1392744 from trunk.
Comment 5 Regina Henschel 2012-10-03 16:42:53 UTC
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"
Comment 6 Oliver-Rainer Wittmann 2012-10-03 18:44:52 UTC
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.
Comment 7 Regina Henschel 2012-10-03 19:00:28 UTC
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.
Comment 8 Oliver-Rainer Wittmann 2012-10-03 19:09:17 UTC
(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
Comment 9 Oliver-Rainer Wittmann 2012-10-03 19:33:10 UTC
My instset of revision 1392744 can be found at people.apache.org/~orw/
Comment 10 Regina Henschel 2012-10-03 20:58:51 UTC
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.
Comment 11 Ariel Constenla-Haile 2012-10-03 22:20:41 UTC
(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/
Comment 12 Oliver-Rainer Wittmann 2012-10-04 05:54:28 UTC
(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
Comment 13 Oliver-Rainer Wittmann 2012-10-04 11:01:57 UTC
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.
Comment 14 Regina Henschel 2012-10-04 13:50:54 UTC
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.
Comment 15 Oliver-Rainer Wittmann 2012-10-04 14:23:03 UTC
(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.
Comment 16 Oliver-Rainer Wittmann 2012-10-04 15:27:21 UTC
I could not reproduce the crash on my Windows 7 and my Windows XP VM after installation on a "long" path.
Comment 17 Regina Henschel 2012-10-04 15:56:26 UTC
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.
Comment 18 Oliver-Rainer Wittmann 2012-10-04 16:00:39 UTC
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?
Comment 19 Regina Henschel 2012-10-04 16:18:35 UTC
(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.
Comment 20 Regina Henschel 2012-10-07 20:34:11 UTC
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
Comment 21 Ariel Constenla-Haile 2012-10-07 20:52:19 UTC
(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.
Comment 22 David 2012-10-17 02:31:26 UTC
I can confirm that this is not reproducible in 3.4.1 (1372287). I'm using Windows 7.
Comment 23 Oliver-Rainer Wittmann 2012-10-22 15:05:08 UTC
(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.
Comment 24 Regina Henschel 2012-11-04 18:55:07 UTC
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.
Comment 25 Oliver-Rainer Wittmann 2012-11-05 16:20:28 UTC
@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.
Comment 26 Regina Henschel 2012-11-06 21:13:41 UTC
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?
Comment 27 Ariel Constenla-Haile 2012-11-06 22:47:33 UTC
Created attachment 79869 [details]
glibc memory map
Comment 28 Ariel Constenla-Haile 2012-11-06 22:48:09 UTC
Created attachment 79870 [details]
GDB backtrace
Comment 29 Ariel Constenla-Haile 2012-11-06 22:50:27 UTC
(In reply to comment #26)
> Where do I find this list in the source?

Look at attachment 79870 [details] it is rather informative :)
Comment 30 Regina Henschel 2012-11-11 14:17:33 UTC
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.
Comment 31 Oliver-Rainer Wittmann 2012-11-13 09:23:00 UTC
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.
Comment 32 Ariel Constenla-Haile 2012-11-13 12:30:57 UTC
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
Comment 33 Oliver-Rainer Wittmann 2012-11-13 13:14:25 UTC
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?
Comment 34 Ariel Constenla-Haile 2012-11-13 13:40:46 UTC
(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,
Comment 35 Oliver-Rainer Wittmann 2012-11-13 13:53:41 UTC
(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.
Comment 36 Ariel Constenla-Haile 2012-11-13 13:53:53 UTC
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).
Comment 37 Oliver-Rainer Wittmann 2012-11-13 14:14:48 UTC
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.
Comment 38 Oliver-Rainer Wittmann 2012-11-13 16:06:22 UTC
Created attachment 79908 [details]
patch to clear reference counting and passing ownership in i18nutil and i18npool

please have a look at the proposed patch.
Comment 39 Regina Henschel 2012-11-13 22:55:11 UTC
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.
Comment 40 Oliver-Rainer Wittmann 2012-11-14 12:21:35 UTC
(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 41 hdu@apache.org 2012-11-15 09:18:34 UTC
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.
Comment 42 Oliver-Rainer Wittmann 2012-11-19 10:14:55 UTC
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
Comment 43 binguo 2012-11-28 08:43:42 UTC
Verified on Aoo_Trunk_20121123.1915 Rev.1412533, no crash, this bug is fixed.
Comment 44 binguo 2012-11-28 08:50:44 UTC
close it