Bug 123466 - Suspicious Log Messages about String comparison
Summary: Suspicious Log Messages about String comparison
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:7.3.0 target:7.2.0.2
Keywords: haveBacktrace
: 131890 (view as bug list)
Depends on:
Blocks: MSO-Formats
  Show dependency treegraph
 
Reported: 2019-02-14 13:48 UTC by ppa
Modified: 2021-07-12 21:49 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Small docx related to the error messages (175.56 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-02-14 13:48 UTC, ppa
Details
console logs (50.14 KB, text/plain)
2019-03-21 20:40 UTC, Julien Nabet
Details
bt with debug symbols (16.12 KB, text/plain)
2019-03-21 20:58 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ppa 2019-02-14 13:48:03 UTC
Created attachment 149297 [details]
Small docx related to the error messages

When I run the attached Java code with the doc attached.
I got the following messages:

CE> E:  file lt-string.c: line 189: assertion `string != ((void *)0)' failed
CE> E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed
CE> E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed
CE> E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed

On different runs the message differ a little bit:
CE> E:  file lt-string.c: line 189: assertion `string != ((void *)0)' failed
CE> E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed
CE> E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed
CE> E:  sfile lt-string.c: line 189: assertion `string != ((void *)0)' failed

It looks like a memory corruption.

Below the Java code calling the SDK:
--------------------------------------------------------
import java.util.Date;
import java.io.File;
import com.sun.star.beans.PropertyValue;
import com.sun.star.comp.helper.Bootstrap;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.frame.XDesktop;
import com.sun.star.frame.XStorable;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.text.XTextDocument;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
import com.sun.star.util.XReplaceDescriptor;
import com.sun.star.util.XReplaceable;

public class LibreOffice {

    public static void main(String[] args) 
    {
        XDesktop xDesktop = null;
        int exitCode = 0;
        
        try {
            // Initialise
            XComponentContext xContext = Bootstrap.bootstrap();
            XMultiComponentFactory xMCF = xContext.getServiceManager();
            Object oDesktop = xMCF.createInstanceWithContext("com.sun.star.frame.Desktop", xContext);
            xDesktop = (XDesktop) UnoRuntime.queryInterface(XDesktop.class, oDesktop);
            documentConvert(xDesktop, "D:/MyData/pdf/docx/toto.docx", "D:/MyData/pdf/pdf/toto.pdf");
            
        }
        catch (Exception e)
        {
            e.printStackTrace();
            exitCode = 1;
        }
        if(xDesktop != null)
           xDesktop.terminate();
        
        System.exit(exitCode);
    }
    
    public static void documentConvert (XDesktop xDesktop, String inputPath, String outputPath) throws Exception 
    {    
       
        // Load the Document
        File inputFile = new File (inputPath);

        if (!inputFile.canRead()) {
            throw new RuntimeException("Cannot load document:" + inputFile);
        }

        XComponentLoader xCompLoader = (XComponentLoader) UnoRuntime.queryInterface(com.sun.star.frame.XComponentLoader.class, xDesktop);

        PropertyValue[] propertyValues = new PropertyValue[0];
 
        propertyValues = new PropertyValue[1];
        propertyValues[0] = new PropertyValue();
        propertyValues[0].Name = "Hidden";
        propertyValues[0].Value = new Boolean(true);
 
        XComponent xComp = xCompLoader.loadComponentFromURL("file:///" + inputPath, "_blank", 0, propertyValues);
        /*
        // save as a PDF 
        XStorable xStorable = (XStorable) UnoRuntime.queryInterface(XStorable.class, xComp);

        propertyValues = new PropertyValue[2];
        propertyValues[0] = new PropertyValue();
        propertyValues[0].Name = "Overwrite";
        propertyValues[0].Value = new Boolean(true);
        propertyValues[1] = new PropertyValue();
        propertyValues[1].Name = "FilterName";
        propertyValues[1].Value = "writer_pdf_Export";
    
        // Appending the favoured extension to the origin document name
        String outputFile = outputPath;
        System.out.println("before");           
        System.out.println(xStorable + "-" + "file:///" + outputFile +  "-" + propertyValues);
        xStorable.storeToURL("file:///" + outputFile, propertyValues);
    
        System.out.println("Saved " + outputFile);
        */
    }
}
Comment 1 ppa 2019-02-14 15:04:25 UTC
In the docx file, there is a reference to a missing style.
Heading2Char is not defined.
This leads to a memory corruption:

<w:style w:type="paragraph" w:styleId="Heading2">
    <w:name w:val="heading 2"/>
    <w:aliases w:val="2"/>
    <w:basedOn w:val="Normal"/>
    <w:next w:val="Normal"/>
    <w:link w:val="Heading2Char"/><!-- bad ref -->
Comment 2 ppa 2019-02-14 15:21:25 UTC
Word skips this style when it loads the document.
Comment 3 ppa 2019-02-14 16:18:19 UTC
My previous assertion about missing ref is wrong.

It seems that the pb for LibreOffice is related to 
<!--<w:lang w:val="x-none" w:eastAsia="x-none"/>-->
Comment 4 ppa 2019-02-18 10:29:36 UTC
it looks like "x-none" is not supported.
Comment 5 Xisco Faulí 2019-03-21 13:31:09 UTC
Confirmed in

Version: 6.3.0.0.alpha0+
Build ID: 7c7a4675ad5d61add70dd073f680ea37012962ce
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

but not in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.15; Render: default; 

no need to run the java code, I get the warning just by opening the file...
Comment 6 Julien Nabet 2019-03-21 20:40:59 UTC
Created attachment 150158 [details]
console logs

On pc Debian x86-64 with master sources updated today, I could reproduce this but had a lot of messages on console.
Comment 8 Julien Nabet 2019-03-21 20:48:23 UTC
Argh, I don't have exactly the same thing,
I've got:
E: lt_string_value: assertion `string != ((void *)0)' failed
whereas this bug indicates:
CE> E:  file lt-string.c: line 189: assertion `string != ((void *)0)' failed
or
CE> E:  l)file lt-string.c: line 189: assertion `string != ((void *)0)' failed
Comment 9 Julien Nabet 2019-03-21 20:51:37 UTC
file lt-string.c: line 189: assertion `string != ((void *)0)' failed
come from workdir/UnpackedTarball/liblangtag/liblangtag/lt-string.c
    178 /**
    179  * lt_string_value:
    180  * @string: a #lt_string_t
    181  *
    182  * Returns the buffer in @string.
    183  *
    184  * Returns: a string which @string has.
    185  */
    186 const char *
    187 lt_string_value(const lt_string_t *string)
    188 {
    189         lt_return_val_if_fail (string != NULL, NULL);
    190 
    191         return string->string;
    192 }
Comment 10 Julien Nabet 2019-03-21 20:58:26 UTC
Created attachment 150160 [details]
bt with debug symbols
Comment 11 Xisco Faulí 2020-04-06 15:51:27 UTC
*** Bug 131890 has been marked as a duplicate of this bug. ***
Comment 12 monyer 2020-04-07 05:01:20 UTC Comment hidden (no-value)
Comment 13 Eike Rathke 2021-07-12 15:24:26 UTC
First, those lt-string assertions do not harm at all (and lt_string_value vs lt-string.c seems to be a liblangtag version difference). They're just an indicator for an unresolved (not IANA registered) BCP 47 language tag, which is kept by LibreOffice though.

Second, MS using 'x-none' that way is non-standard. All 'x-...' language tags are reserved for *private* use (*private-use subtags by definition are not interoperable*), but MS doesn't use them so privately if it lets them escape into the wild and any application encountering them can do whatever it wants, including completely ignoring them. Unless it wants to follow a private agreement with the creator (here MS-Word). Is that 'x-none' documented anywhere?
Comment 14 Commit Notification 2021-07-12 20:01:28 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4e0a7df2dfa10bc52d5dbda34f43e0bc0df22ae7

Resolves: tdf#123466 Add Microsoft ill-used {x-none} to known language tags

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Eike Rathke 2021-07-12 20:02:10 UTC
Pending review https://gerrit.libreoffice.org/c/core/+/118794 for 7-2
Comment 16 Commit Notification 2021-07-12 21:49:43 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/815817fa8f5c04bd20965691d72c83659b082745

Resolves: tdf#123466 Add Microsoft ill-used {x-none} to known language tags

It will be available in 7.2.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.