Issue 113898 - Writer crashes when pasting on a new document
Summary: Writer crashes when pasting on a new document
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOO330m4
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
Keywords: regression
Depends on:
Blocks: 111112
  Show dependency tree
Reported: 2010-08-15 10:48 UTC by santiago.bosio
Modified: 2017-05-20 11:42 UTC (History)
3 users (show)

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

One of the files that makes it crash (16.75 KB, application/vnd.oasis.opendocument.text)
2010-08-18 17:46 UTC, santiago.bosio
no flags Details
patch catching a possible BULL ptr (759 bytes, patch)
2010-08-20 08:28 UTC, philipp.lohmann
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description santiago.bosio 2010-08-15 10:48:44 UTC
I have tested this on my own builds and on the last OOO330_m4 build by RE team.

Steps to reproduce:

1) Open an OpenDocument text file.
2) Choose Edit -> Select all.
3) Choose Edit -> Copy.
3) Create a new text document.
4) Choose Edit -> Paste.

Writer crashes every time, with all documents.

I tested on my Ubuntu 8.04. Please, try to reproduce and confirm this issue. If
you can confirm it, it should be raised as showstopper for the upcoming 3.3.0.

Best regards,

Comment 1 michael.ruess 2010-08-18 10:14:11 UTC
Cannot reproduce with OOO330m4 on WinXP or SUSE 11. 
Does this happen with every document on your system?
Comment 2 santiago.bosio 2010-08-18 11:53:27 UTC
No, it doesn't happens with all documents, but there are at least a couple of
them that make this to happen.

I've send those documents to other spanish collaborators, and they don't have
this problem, but they have other system versions.

I've been testing with my own builds and with the ones provided by the RE team
and both failed. I have even deleted my user configuration directory to start
with a newly created one, but it also failed.

I'm currently compiling with debug symbols to be able to provide a backtrace for
you. Expect it later today or tomorrow (I don't have a good build box, and it
takes too much time to compile OOo).

Best regards,

Comment 3 michael.ruess 2010-08-18 15:49:35 UTC
Could you attach one of the documents where this happens?
Comment 4 santiago.bosio 2010-08-18 17:43:42 UTC
This is the backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb481c8d0 (LWP 21879)]
atk_wrapper_focus_idle_handler (data=0xab5f91d8)
    at /home/sbosio/
95	                if( !wrapper_obj->mpText && wrapper_obj->mpContext )
Current language:  auto; currently c++
(gdb) bt
#0  atk_wrapper_focus_idle_handler (data=0xab5f91d8)
    at /home/sbosio/
#1  0xb3823101 in ?? () from /usr/lib/
#2  0xb3824cf6 in g_main_context_dispatch () from /usr/lib/
#3  0xb38280b3 in ?? () from /usr/lib/
#4  0xb382866e in g_main_context_iteration () from /usr/lib/
#5  0xb3e4b18e in GtkXLib::Yield (this=0xb4811908, bWait=true, 
    at /home/sbosio/
#6  0xb37aea97 in X11SalInstance::Yield (this=0xb3fef648, bWait=false, 
    bHandleAllCurrentEvents=<value optimized out>)
    at /home/sbosio/
#7  0xb5ee5131 in ImplYield (i_bWait=true, i_bAllEvents=<value optimized out>)
    at /home/sbosio/
#8  0xb5ee1f24 in Application::Yield (i_bAllEvents=false)
    at /home/sbosio/
#9  0xb5ee3eef in Application::Execute ()
    at /home/sbosio/
#10 0xb754e906 in desktop::Desktop::Main (this=0xbf9278b4)
    at /home/sbosio/
#11 0xb5ee82a5 in ImplSVMain ()
    at /home/sbosio/
#12 0xb5ee83b3 in SVMain ()
---Type <return> to continue, or q <return> to quit---
    at /home/sbosio/
#13 0xb756c07a in soffice_main ()
    at /home/sbosio/
#14 0x08048cc4 in main ()

I will upload the document also.

If there's something else I can do, please indicate it.
Comment 5 santiago.bosio 2010-08-18 17:46:23 UTC
Created attachment 71170 [details]
One of the files that makes it crash
Comment 6 michael.ruess 2010-08-19 14:41:27 UTC
Works fine even with the attached document on my ubuntu 10.04. Does it help when
you delete the config folder ~/.ooo-dev (or similar)?

MRU->PL: I can see only vcl and something like gtk on the backtrace. Do you have
an idea?
Comment 7 philipp.lohmann 2010-08-19 15:57:17 UTC
Not really, from the stacktrace it might be that wrapper_obj is NULL. Seeing two
documents and a focus change involved, these is probably timing dependent and
therefore not reliably reproducible everywhere (incidentally not for me either,

If I compiled a set of libraries for you that catches that presumed NULL
pointer, would you be willing to try them with your office installation ? The
version would be OOO330m4 like described above ?
Comment 8 santiago.bosio 2010-08-19 19:42:56 UTC
sbosio -> mru: Yes, it was what I first tried, to delete the user configuration
directory, but it doesn't help neither.

sbosio -> pl: If you can provide those libraries, and tell me how to proceed
with them, I have no problem at all. The last version I built is Mercurial tag
OOO330_m4, and it happened also with the previous ones, but not with the
previous release OOO320_mXX.
Comment 9 philipp.lohmann 2010-08-20 08:27:32 UTC
At you can
find a library that should catch a NULL ptr at this point. You can exchange it
with the version at <openoffice_root>/basis3.3/program (please make a backup of
the original first). If that was actually the problem, this library should fix it.

I'll also attach a patch with the (trivial) change.
Comment 10 philipp.lohmann 2010-08-20 08:28:26 UTC
Created attachment 71214 [details]
patch catching a possible BULL ptr
Comment 11 santiago.bosio 2010-08-20 12:53:07 UTC
sbosio -> pl: It doesn't crash with the patched library, so you were right,
wrapper_obj is NULL, and it was causing that behaviour. Now, I don't know why it
seems to be NULL only in my system.
Comment 12 philipp.lohmann 2010-08-20 13:20:38 UTC
I can't tell you for sure. Anyway that patch is safe, so we should apply it by
all means. And we can consider this issue confirmed now I guess.

@mru: I have no idea how often this happens to people. Considering the safety of
this patch (it just catches an obvious erroneous condition), you might consider
this for 3.3.
Comment 13 philipp.lohmann 2010-08-20 13:22:07 UTC
assign to me
Comment 14 michael.ruess 2010-08-20 14:33:14 UTC
MRU->PL: should be no problem to have this is in 3.3; crash and regression from
3.2.1 is a quite good criteria. However, thank you for caring about this so quick!
Comment 15 philipp.lohmann 2010-08-20 16:15:38 UTC
committed in CWS ooo33gsl07
Comment 16 santiago.bosio 2010-08-24 13:07:27 UTC
I just wanted to comment that investigating further I've found that on GNOME
preferences I'd support for assistive technologies active, even when I didn't
use any of them, but deactivating them took away the crashes even on the not
patched builds.

Perhaps that's why no one could reproduce this problem, but again, it didn't
happen with 3.2.1, so something must have changed on code related to
accessibility features and its integration with GNOME.

Checking for that NULL pointer solved the crash problem, but I'm wondering if
that pointer it's not supposed to be NULL when you really have activated
accessibility tools, and it being NULL on 3.3.0 means that the support for
accessibility features in OOo 3.3 is broken and will not work at all.

Is out there anybody that can check accessibility features on the OOO330 branch?
I have no idea how are they supposed to work, to try myself.
Comment 17 philipp.lohmann 2010-08-24 14:16:03 UTC
@es: any insight on this ?
Comment 18 philipp.lohmann 2010-08-24 15:48:40 UTC
unfortunately it does not crash for me with gnome accessibility (and orca
active) either, so it's hard to say what may be missing. In light of this I
propose to go on with the crash prevention and if there is some functionality
missing there will be hopefully a bug report.
Comment 19 philipp.lohmann 2010-08-24 17:53:25 UTC
@es: on my machine the issue did not occur, perhaps it does on your's ? If so,
please verify in CWS ooo33gsl07, thanks.
Comment 20 eric.savary 2010-08-25 16:21:20 UTC
Reproduced in master and fix verified in CWS ooo33gsl07.

Found an assertion while pasting with A11y ON (only)
F'up issue 114104.