Issue 90076 - Crash in ScCellRangesBase::Notify
Summary: Crash in ScCellRangesBase::Notify
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: OOo 2.4.1 RC1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-05-28 16:02 UTC by pmladek
Modified: 2017-05-20 11:11 UTC (History)
2 users (show)

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

the workaround (830 bytes, patch)
2008-05-28 16:03 UTC, pmladek
no flags Details | Diff
gdb log with the backtrace (35.91 KB, text/plain)
2008-05-28 16:05 UTC, pmladek
no flags Details
the valgrind log showing that the memory is accessed after it is removed (292.93 KB, text/plain)
2008-05-28 16:06 UTC, pmladek
no flags Details
cellsuno.cxx patched by ooo-build that were used to produce the various logs (328.82 KB, text/plain)
2008-05-28 16:12 UTC, pmladek
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description pmladek 2008-05-28 16:02:38 UTC
I tested the build based on ooh680-m16 sources and ooo-build-2-4-1 branch. It
crashed on the C# sample that could be found in /odk/examples/CLI/CSharp/Spreadsheet

The crash happend in sc/source/ui/unoobj/cellsuno.cxx in
ScCellRangesBase::Notify when it tried to call


The attached backtrace shows that the object this did not exist at that time.
More dubugging showed it was most likely removed on the end of

     ScTableSheetObj::getImplementation( (cppu::OWeakObject*)this )

Note that the method is defined the following way:

     ScTableSheetObj* ScTableSheetObj::getImplementation( const 
         uno::Reference<uno::XInterface> xObj )

so there is created the temporary uno::Reference. The object "this" was probably
destructed together with this temporary reference.

I'll attach a patch that makes sure that the temporary object lives a bit
longer. It is only a workaround. I am not sure how it is supposed to work.
Comment 1 pmladek 2008-05-28 16:03:38 UTC
Created attachment 54032 [details]
the workaround
Comment 2 pmladek 2008-05-28 16:05:33 UTC
Created attachment 54033 [details]
gdb log with the backtrace
Comment 3 pmladek 2008-05-28 16:06:33 UTC
Created attachment 54034 [details]
the valgrind log showing that the memory is accessed after it is removed
Comment 4 pmladek 2008-05-28 16:09:52 UTC
Search the valgrind log for "cellsuno.cxx:1642" to find the revelant part.
Comment 5 pmladek 2008-05-28 16:12:04 UTC
Created attachment 54035 [details]
cellsuno.cxx patched by ooo-build that were used to produce the various logs
Comment 6 pmladek 2008-06-03 17:36:28 UTC
We found another way to reproduce this crash, see

I was not able to reproduce it by the Sun's OOo-2.4.1rc2 build. I am not sure if
it is ooo-build-specific or if it works in the Sun's build just by chance.

Is anyone more familiar with that code?
Comment 7 niklas.nebel 2008-06-04 15:51:57 UTC
You get the same crash if you load a file and manually delete a column? No API
calls or other threads involved? Then I can't imagine why there is an object
with refcount 0 to begin with.
Comment 8 niklas.nebel 2008-12-09 17:45:45 UTC
Target 3.x, as I still can't imagine how this should occur without API calls or
other threads.
Comment 9 Rob Weir 2013-03-11 14:58:56 UTC
I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:


Comment 10 Marcus 2017-05-20 11:11:34 UTC
Reset assigne to the default "".