The Talks and Slides by Collaboran’s at the LibreOffice Conference 2022

One category of the bugs that we see in computer programs including LibreOffice is the unexpected crashes. You’re working with the application, and it is suddenly closed! In the previous part, I have discussed crashes that are caused by segmentation fault. In this article, I discuss the crashes from invoking abort() function. Please note that not an abort is not always a bad thing, or a bug.

Abort

In C/C++ sometimes we have to check the validity of certain conditions, and avoid certain bad situations. We do that to avoid data corruption or other problems that leads us to terminate the application instead of trying to continue.

This is different from normal error handling routines, because in error handling, we usually try to find errors, find ways out of the problem automatically, or ask user to fix the problem by changing the input and things like that. But, this is not always the case.

Better to Be Safe Than Sorry!

If you search for abort in the .cxx files, you will find a lot abort() usages:

git grep "abort(" *.cxx

Let’s look at some example. When writing tests, one of the problems that may occur while testing font rendering is the font fallback because of using fonts that are not available via LibreOffice. In this situation, it is better to stop the test application, so that the developers understand that they should use fonts that are available via LibreOffice. You can look vcl/unx/generic/fontmanager/fontconfig.cxx for more information.

Another example is the problem with the GPU. If you look at vcl/skia/gdiimpl.cxx, you can see this code. The comments explain the situation. When we run out of memory, the error is “unrecoverable without possible data loss”. So, the best thing that we can do, is to abort the program.

// If there's a problem with the GPU context, abort.
if (GrDirectContext* context = GrAsDirectContext(mSurface->getCanvas()->recordingContext()))
{
    // Running out of memory on the GPU technically could be possibly recoverable,
    // but we don't know the exact status of the surface (and what has or has not been drawn to it),
    // so in practice this is unrecoverable without possible data loss.
    if (context->oomed())
    {
        SAL_WARN("vcl.skia", "GPU context has run out of memory, aborting.");
        abort();
    }
    // Unrecoverable problem.
    if (context->abandoned())
    {
        SAL_WARN("vcl.skia", "GPU context has been abandoned, aborting.");
        abort();
    }
}

Generally speaking, the developer should try to recover from the errors, but in the end, some unrecoverable errors may remain, and the developer might decide to do an abort().

Fixing Bugs Related to abort

On the other hand, sometimes it is possible to avoid doing an abort(), and recover from an error. In such a case, fixing the crash would involve finding a way out of the problem, and continuing the normal execution of the program.

For example, take a look at tdf#138022 – LibreOffice exits/crashes when minimizing start center after closing a document (SKIA).  This issue is fixed in this patch …

As discussed in the “crash fixes for LibreOffice, part 1: segfaults“, bugs that lead to crash in LibreOffice or other native applications can have different causes, and therefore need completely different fixes. Some of these bugs are hard to fix: you have to change the behavior of the application in order to avoid crashes.

On the other hand, there are some cases that a fix can be simple checking for a pointer to make sure that it is not NULL/nullptr before actually using it. Or, making sure that a variable has properly initialization before its use. In these cases, fixing the bug is not too hard, and a fix can be provided very quickly.

Example EasyHacks Related to Crashes

Thanks to Mike, this week we have 2 new EasyHacks of this kind:

• tdf#150135 – Accessing uninitialized TextInputStream methods crashes

When accessing uninitialized a TextInputStream, an exception should be thrown, in which leads to Basic run-time error. Instead, because of lack of appropriate checks, it leads to a crash.

You can debug and see the crash point by executing this LibreOffice BASIC code snippet:

Sub crash
  stream = CreateUnoService("com.sun.star.io.TextInputStream")
  stream.available()
End Sub

To fix this bug, one should take a look at OTextInputStream code inside core/io/source/TextInputStream/TextInputStream.cxx:53 and make sure to check and throw runtime exception where appropriate.

• tdf#150137 – Crash when parsing an XML with undeclared namespace

This second issue is a crash that happens when parsing an XML with undeclared namespace. To catch and debug such a crash, you should create a tiny xml file as described in the bug report:

<?xml version="1.0" encoding="UTF-8"?>
<a:xml/>

Then, try to parse it with this LibreOffice BASIC script:

Sub Parse
  source = CreateUnoStruct("com.sun.star.xml.sax.InputSource")
  source.aInputStream = CreateUnoService("com.sun.star.ucb.SimpleFileAccess").openFileRead(ConvertToURL("path/to/file.xml"))
  parser = CreateUnoService("com.sun.star.xml.sax.FastParser")
  parser.ParseStream(source)
End Sub

Then, you will see that the crash happens in this part of the code in core/sax/source/fastparser/fastparser.cxx:1281:

if ( !m_bIgnoreMissingNSDecl || URI != nullptr   )
    sNamespace = OUString( XML_CAST( URI ), strlen( XML_CAST( URI )), RTL_TEXTENCODING_UTF8 );

If you look closely, you will understand that if m_bIgnoreMissingNSDecl is false, then the URI check to make sure that it not nullptr is not happening. And dereferencing nullptr leads to crash.

The above two EasyHacks are good for the newcomers. So, if you have some knowledge on C++ and you are able to build LibreOffice, you can work on these issues. If so, first try to gain a basic understanding of the problem. Then assign the bug to yourself and try to fix it.

Writing Tests for Crash Fixes

Writing tests for the crash is also not a very hard task. Either a CppUnitTest, or a UITest can do the exact things that leads to crash without a fix. Then, the test will fail if a crash occurs preventing the same problem in the future.

If you …

One of the bugs that we see in computer programs including LibreOffice is the crash. You’re working with the application, and the program is suddenly closed! Here we discuss the usual causes for these crashes, and how to fix some of them.

Crash Report

There can be many reasons for a crash in C/C++, including segmentation faults (segfaults), assertion failures, aborts, and exceptions that lead to abort. Here we discuss the segmentation faults.

Usual Causes for the Segmentation Fault Crashes

There can be many reasons for a segfault in C/C++, and most of them are are related to the incorrect use of memory. For example:

1. Accessing memory that the program does now own
2. Using memory outside the allocated parts
3. Using uninitialized variables

If you use a variable without properly initializing it, that may lead to a segfault. For example:

int main() {
    int *p;
    *p = 1;
    return 0;
}

Trying to de-reference a null pointer also leads to crash.

int main() {
    int *p = nullptr;
    *p = 1;'
    return 0;
}

$ g++ main.cpp -o main; ./main
Segmentation fault (core dumped)

In C/C++, most compilers do not check the array bounds automatically. When working with arrays, you have to take care that you are accessing inside the array bounds, and not beyond them. Look at this example:

int main() {
    int a[10];
    a[1000000] = 1;
    return 0;
}

When working with pointers, it is important to make sure that the pointer is not null before working with it. For example, look at this file:

sc/source/ui/view/tabview.cxx

Inside it, look at this method:

bool lcl_HasRowOutline( const ScViewData& rViewData )
{
    const ScOutlineTable* pTable = rViewData.GetDocument().GetOutlineTable(rViewData.GetTabNo());
    if (pTable)
    {
    const ScOutlineArray& rArray = pTable->GetRowArray();
    if ( rArray.GetDepth() > 0 )
        return true;
    }
    return false;
}

Here, before working with pTable, with the condition “if (pTable)“, we make sure that the pTable pointer is not null.

That is also the case when working with arguments. Look at this function inside the same file:

IMPL_LINK_NOARG(ScTabView, TimerHdl, Timer *, void)
{
    if (pTimerWindow)
        pTimerWindow->MouseMove( aTimerMEvt );
}

The condition makes sure that pTimerWindow is not null.

How to Fix the segfaults?

To describe how to fix some of the segfaults, I discuss to fixes that are merged recently by Caolan and me.

First, please take a look at this recently fixed crash by Caolan:

• Resolves: tdf#150629 the window was destroyed from the fadetimer callback

The crash was happening when you created a page break, and then tried to edit it. The backtrace showed that the problem is happening in this file:

sw/source/uibase/docvw/PageBreakWin.cxx

inside this method:

IMPL_LINK_NOARG(SwPageBreakWin, FadeHandler, Timer *, void)

just in this line, when invoking IsVisible().

if (IsVisible( ) && m_nFadeRate > 0 && m_nFadeRate < 100)
    m_aFadeTimer.Start();

In a debug session for LibreOffice, one can see that the window object is actually destroyed, but the code wants to check if the window is visible or not. In this way, it leads to a segfault. Looking carefully, it becomes visible that the …

Open Document Format (ODF) is a standard (ISO/IEC 26300) and native file format that LibreOffice uses. OASIS developed this file format based on the file format of StarOffice, the ancestor of LibreOffice.

To understand the ODF standard, working with the LibreOffice code and fixing a small bug is enlightening. Here we discuss a related EasyHack.

ODF File Extensions

If you are a LibreOffice user, you may already know these extensions:

.odt for text processing documents (LibreOffice Writer)

.odp for presentations (LibreOffice Impress)

.ods for spreadsheets (LibreOffice Calc)

.odg for drawings (LibreOffice Draw)

.odf for formulas (LibreOffice Math)

Essentially, these are zip files containing XML and binary files. Additionally, Open Document Format can also be text-only format with the extensions of .fodt, .fods and .fodg instead of .odt, .ods, and odg respectively.

Open Document Specification

OASIS website provides the documents that describe the Open Document Format extensively . You can find the specifications for ODF 1.3, which is the latest version of the standard here:

OpenDocument V1.3 OASIS Standard published

Beside LibreOffice, several other applications support ODF standard, including Microsoft Office, ONLYOFFICE, Calligra Suite, Google Docs, and many others! But here, we focus on LibreOffice.

Basically, LibreOffice handles the Open Document format by opening the zip file using the zip parser and the deflate algorithm, and then parses the XML files inside it using libxml2 library.

On the other hand, the meaning of the XML tags and attributes are available via the specification from OASIS. In essence, the specification describes the text, pictures, shapes and other elements of the text processing, presentations, spreadsheets and formulas. Additionally, ODF standard discusses accessibility, collaboration and many more topics.

An EasyHack Related to ODF

To best way to understand the ODF standard, is working with the LibreOffice code. Please take a look at this small bug, which has the label of EasyHack (tdf#150302):

• Bug 150302 – Toggle SameLetterHeights does not work if property not initialized

In this EasyHack, there is a sample document which is using a specific feature in the drawings. Looking at the <draw:enhanced-geometry> tag, one can see that there is an attribute draw:text-path-same-letter-heights that is used to control the way that text is rendered in shapes. It is described in ODF standard as:

19.224 draw:text-path-same-letter-heights

The draw:text-path-same-letter-heights attribute specifies if all letters in a custom shape have the same height.

The defined values for the attribute are:

• false: letters in a custom shape need not have the same height.
• true: letters in a custom shape have the same height.

The default value for this attribute is false.

The issue is that handling this parameter in the code is not correct. Specifically, the effect of this bug is that if you open the sample file and click on the SameLetterHeights button in the Fontwork toolbar, nothing happens. On the other hand, the correct behavior should be that the shape changes, and “shows the characters vertical stretched to fit the place between the paths”.

Shapes inside the …