Non-breaking space (doubled) bug

[DiapDealer]

The non-breaking-space doubling issue is still happening even when building from scratch on Debian.

[KevinH]

Hi,

Could it be differences in compilers? Which version of gcc are you using on Debian? And which version on Mint? Will the Mint compiled version run on the older Debian? Wouldn't it need a new C++ runtime library?

So if on Mint they have a new C++ runtime library from a newer gcc. We do not include the c++ runtime library (libstdc++) when shipping binaries on Linux do we? So if you move the Mint version (which worked perfectly) to a system with a much older gcc and g++ runtime library (older libstdc++) installed (but same major number) such as Debian, you might see bugs that don't exist on Mint.

Kevin

[Doitsu]

Originally Posted by DiapDealer

They'd need to do something like:

LD_LIBRARY_PATH=/usr/local/share/sigil ldd /usr/local/share/sigil/sigil-real

Please find attached the output of the above command from my Debian Wheezy system.

[DiapDealer]

Originally Posted by KevinH

Hi,

Could it be differences in compilers? Which version of gcc are you using on Debian? And which version on Mint? Will the Mint compiled version run on the older Debian? Wouldn't it need a new C++ runtime library?

My Mint compiled binary package seems to run on Debian (with the exception of that doubling bug). The packages are built using one of the oldest versions of Mint/glibc/gcc I can get Sigil to compile with (gcc 4.6.1) in the hopes of supporting the widest (and oldest) range of debian/ubuntu systems out there.

Originally Posted by KevinH

So if on Mint they have a new C++ runtime library from a newer gcc. We do not include the c++ runtime library (libstdc++) when shipping binaries on Linux do we? So if you move the Mint version (which worked perfectly) to a system with a much older gcc and g++ runtime library (older libstdc++) installed (but same major number) such as Debian, you might see bugs that don't exist on Mint.

That would definitely be the case if the Debian distros in question had an older version of glibc/gcc than my build environments, but that doesn't seem to be the case here. I build with gcc 4.6.1 and the Wheezy system I tested on had gcc 4.7.2. But that seems to be moot anyway, as building Sigil from scratch on the Debian system exhibited the same "doubling" issues.

[DiapDealer]

Originally Posted by Doitsu

Please find attached the output of the above command from my Debian Wheezy system.

Thanks. It definitely appears to using only the Qt5 libraries included with the package.

[KevinH]

Hi,

If a binary works on one Linux system Mint with the exact same Qt libraries yet doesn't work correctly on another Linux machine, it must be differences in one of the shared libraries.

Looking at Doitsu's list should show us all of the shared libraries that are used by Sigil on Linux. So we can start with it and remove all of the libraries with sigil in the path name:

I think we can probably remove the X11 related libraries as well as basic shared library ones like ld and libdl. We can also remove the gcc related ones given what you wrote as well as things like the threading libraries.

That leaves us with this list:

        linux-vdso.so.1 =>  (0x00007fff1efff000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f97045ac000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f97042b3000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9703d70000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9703b58000)
        libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007f9702d37000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f97029d6000)
        libgstreamer-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstreamer-0.10.so.0 (0x00007f97026ee000)
        libgstapp-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstapp-0.10.so.0 (0x00007f97024e1000)
        libgstbase-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstbase-0.10.so.0 (0x00007f970228b000)
        libgstinterfaces-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstinterfaces-0.10.so.0 (0x00007f9702079000)
        libgstpbutils-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstpbutils-0.10.so.0 (0x00007f9701e54000)
        libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f9700508000)
        libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f96ffea8000)
        libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5 (0x00007f96ffc9b000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f96ffa5d000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f96ff83d000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f96fdf91000)
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f96fdd8d000)
        liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f96fdb0f000)
        libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f96fd8ea000)
        libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f96fcaa2000)

The only one that jumps out as me as being possibly related is libxml2

libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f97029d6000)

which links directly into Qt and could cause an issue with text nodes in an xml tree.

But this is all a big guess. We do know there have been a lot of bugs fixed in libxml2. Could you try updating the Wheezy one to be the same version as used on Mint and see if that impacts anything?

If is not that one, we could simply try a process of elimination of some sort I guess, but if one binary works on one system and the exact same binary does not work on another system, it must be one of the shared libraries at fault (unless I am missing something here).


KevinH

[DiapDealer]

Originally Posted by KevinH

The only one that jumps out as me as being possibly related is libxml2

libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f97029d6000)

which links directly into Qt and could cause an issue with text nodes in an xml tree.

But this is all a big guess. We do know there have been a lot of bugs fixed in libxml2. Could you try updating the Wheezy one to be the same version as used on Mint and see if that impacts anything?

If is not that one, we could simply try a process of elimination of some sort I guess, but if one binary works on one system and the exact same binary does not work on another system, it must be one of the shared libraries at fault (unless I am missing something here).

I'll give it a shot (if only for my own curiosity) but even if that shared library turns out to be the culprit, do we have real shot at fixing it or supplying a workaround (short of custom compiling Qt5 to use a newer, supplied libxml2)?

[Doitsu]

Originally Posted by DiapDealer

I'll give it a shot (if only for my own curiosity) but even if that shared library turns out to be the culprit, do we have real shot at fixing it or supplying a workaround (short of custom compiling Qt5 to use a newer, supplied libxml2)?

The current stable Debian Wheezy distro comes with libxml2-2.8.0, however, the latest upstream version is libxml2-2.9.2-2.

@DiapDealer: Since I can't update this library via Debian backports to the latest version, you could try and temporarily downgrade your libxml2 version to 2.8.0 to test if that change will cause the OP's issue.

If that library is indeed causing the problem, the only fix would be installing a more bleeding-edge distro.

[DiapDealer]

Got something I need to try when I get home. I don't edit in Book View, so I'm pretty guilty of not checking for issues there (actually, past experience has just taught me to assume there are ... so I don't do it.

In short, I haven't checked the aging VMs I build and test Sigil on to see if they suffer from the bug. I can't imagine Mint 12 (Ubuntu 11.10) having a newer version of libxml2 than the Debian Wheezy (7.8) I installed, so either those systems should suffer the same doubling bug or it's something other than libxml2.

I'll check the libxml versions on my build/test/main machines and see what I come up with.

[KevinH]

FWIW,

I did all of my testing (and found no bug) against the very very latest Mint 13 (I think) that I just installed a few weeks back. If it does turn out to be libxml2 related or some other library like that, we can simply package it up and store a version of it in the sigil/ directory and set it to find that lib via LD_LIBRARY_PATH before the official one.

No need to update the os.

KevinH

[DiapDealer]

Originally Posted by KevinH

FWIW,

I did all of my testing (and found no bug) against the very very latest Mint 13 (I think) that I just installed a few weeks back. If it does turn out to be libxml2 related or some other library like that, we can simply package it up and store a version of it in the sigil/ directory and set it to find that lib via LD_LIBRARY_PATH before the official one.

No need to update the os.

KevinH

I think you installed Mint 17.1 if I recall correctly.

I'll see what I can track down. I may be saddled with snow-removal duties this weekend, but I'd love it if that didn't work out.

[JSWolf]

I'm using Windows 7 32-bit and Sigil 0.8.4. I don't get a double non-breaking-space when spacing in code view.

[DiapDealer]

Originally Posted by JSWolf

I'm using Windows 7 32-bit and Sigil 0.8.4. I don't get a double non-breaking-space when spacing in code view.

We know.

[DiapDealer]

I don't think it's libxml2

The machine I build the packages on has libxml2 v2.7.8. And that machine does NOT exhibit the doubling behavior when Sigil is run on it. Non-breaking space treatment is consistent with the way Windows, OSX (and other tested Linux systems) behave.

The Wheezy I installed has a newer libxml2 v2.8.0 and DOES exhibit the behavior.

[KevinH]

Wow!

Okay, so much for my guess :-(

And yes I think it was Mint 17. I will go home and see what version of libxml2 it uses.

Thanks for trying it.

Kevin