Issue 103591 - crash on leaving text edit in layout placeholder
Summary: crash on leaving text edit in layout placeholder
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: ui (show other issues)
Version: DEV300m52
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Armin Le Grand
QA Contact: issues@graphics
URL:
Keywords: needmoreinfo
Depends on:
Blocks:
 
Reported: 2009-07-16 17:01 UTC by Joe Smith
Modified: 2009-09-04 23:41 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Joe Smith 2009-07-16 17:01:12 UTC
Testing DEV300_m52 on Fedora Linux 11

1) File > New > Presentation > Create
2) Select any layout that includes a text placeholder, e.g. #2, "Title Slide"
3) Click in the title item to edit the title text
4) Impress crashes on leaving the text edit mode, either by pressing "Esc" or by 
clicking outside the layout item.

Reproducible 100%; same with any layout/any text item.

Graphics item (image/chart) or text box is ok.
Comment 1 wolframgarten 2009-07-17 11:36:26 UTC
Sorry, not reproducible. Are these original OOo builds you are using or from
some other source? Have you been asked to send a crash report and did you
receive a crash ID after doing this?
Comment 2 Joe Smith 2009-07-17 15:50:24 UTC
Ok, thanks for having a look.

It seems that the crash depends on how I'm logged in when I run OOo. If I'm
logged in as a console user, m52 runs fine--no crash. If I'm logged in through a
terminal session, then it crashes.

I normally log in to the system console using my personal account, then (from a
terminal window) su to a test user account and start OOo from the terminal
session. OOo is uses the display from my personal account but running as my test
user. This is the first time I've had any problem running OOo this way.

If I instead log in on the console as the test user (or get a second console
session through "switch user") and run OOo, then it runs fine. In that case, OOo
and the display both belong to the test user.

I repeated the crash and had it send a crash report this time but I didn't see
any ID mentioned. I can attach the crash report file or the terminal session
messages if anyone wants to follow up, but it seems like a low-priority scenario.
Comment 3 wolframgarten 2009-07-20 08:02:34 UTC
If you send a crash report you normally get an answer email to the used email
adress containing a line like "The ID of the error report is rds5ukc."
Comment 4 Joe Smith 2009-07-20 14:55:25 UTC
Ok, got it:

> The ID of the error report is rv9pukc.
Comment 5 wolframgarten 2009-07-20 15:00:01 UTC
Thanks, reassigned.
@cl : anything visible from the stack?
Comment 6 clippka 2009-07-20 17:32:29 UTC
it looks like accessibility support triggers this bug. but the actual crash
looks familiar

3 	0xb28111ad 	0x4571ad 	libsvxli.so 	_ZNK14EditTextObjecteqERKS_+0x11 
$program/program
5 	0xb285a414 	0x4a0414 	libsvxli.so 	_ZNK18OutlinerParaObjecteqERKS_+0x22 
$program/program
11 	0x675444c 	0x4444c 	libdrawinglayerli.so 
_ZN12drawinglayer11primitive2d29arePrimitive2DReferencesEqualERKN3com3sun4star3uno9ReferenceINS3_7graphic12XPrimitive2DEEESA_+0x88
	$program/program
12 	0x67544c0 	0x444c0 	libdrawinglayerli.so 
_ZN12drawinglayer11primitive2d28arePrimitive2DSequencesEqualERKN3com3sun4star3uno8SequenceINS4_9ReferenceINS3_7graphic12XPrimitive2DEEEEESC_+0x62
	$program/program
13 	0xb2a27e6f 	0x66de6f 	libsvxli.so 
_ZNK3sdr7contact11ViewContact37getViewIndependentPrimitive2DSequenceEv+0x2d 
$program/program
14 	0xb261e47f 	0x26447f 	libsvxli.so 	_ZN9SdrObject15RecalcBoundRectEv+0x5b 
$program/program
15 	0xb26167b9 	0x25c7b9 	libsvxli.so 
_ZNK9SdrObject19GetCurrentBoundRectEv+0x2f 	$program/program
16 	0xb296bd4a 	0x5b1d4a 	libsvxli.so 
_ZN8SvxShape20getPropertyValueImplERKN3rtl8OUStringEPK26SfxItemPropertySimpleEntryRN3com3sun4star3uno3AnyE+0x5b2
	$program/program
17 	0xb296c9db 	0x5b29db 	libsvxli.so 
_ZN12SvxShapeText20getPropertyValueImplERKN3rtl8OUStringEPK26SfxItemPropertySimpleEntryRN3com3sun4star3uno3AnyE+0x93
	$program/program
18 	0xb296ce81 	0x5b2e81 	libsvxli.so 
_ZN8SvxShape17_getPropertyValueERKN3rtl8OUStringE+0xa3 	$program/program
20 	0xb296d048 	0x5b3048 	libsvxli.so 
_ZN8SvxShape16getPropertyValueERKN3rtl8OUStringE+0x30 	$program/program
21 	0xb29dd4c3 	0x6234c3 	libsvxli.so 
_ZN13accessibility15AccessibleShape9getBoundsEv+0x1d1 	$program/program
22 	0xb29dac45 	0x620c45 	libsvxli.so 
_ZN13accessibility15AccessibleShape11getLocationEv+0x2f 	$program/program
23 	0xb29dc3a4 	0x6223a4 	libsvxli.so 
_ZN13accessibility15AccessibleShape19getLocationOnScreenEv+0x2c 	$program/program
Comment 7 Armin Le Grand 2009-07-30 17:16:17 UTC
AW: Maybe double to #i101239# need to check with DEV300 m54 (where aw073 is added)
Comment 8 Armin Le Grand 2009-08-05 16:01:18 UTC
AW: probably double to #i102534# and thus to to #i103982#, especially with the
stack and EmptyPresObjs involved. Waiting for CWS aw075 integration, where this
task does not happen.
Comment 9 Armin Le Grand 2009-08-05 16:02:33 UTC
AW: Changed comment
Comment 10 Joe Smith 2009-08-05 22:14:01 UTC
Same crash in DEV300_m54, but release notes don't show aw075 in the list of
integrated cws.
Comment 11 Armin Le Grand 2009-08-06 12:19:23 UTC
AW->jes: CWS aw075 is in progress (just closing), so of course not integrated.
Please derive CWS information from openoffice.org.
Comment 12 Armin Le Grand 2009-09-03 12:32:20 UTC
AW: Checked with unxlngi6.pro of DEV300 m57 where aw075 is integrated. No crash
anymore. Setting to fixed.
Comment 13 Armin Le Grand 2009-09-03 12:32:52 UTC
AW. Closing
Comment 14 Joe Smith 2009-09-04 23:41:43 UTC
Testing DEV300_m57 on Linux (Fedora 11)

Problem is fixed: no more crash.

Thank you!