BC3 segfault (or slow to start) with glibc 2.24

[mikko]

Almost one year ago I had a problem with slow startup with BC3 under Linux when upgrading glibc to version 2.22. After some struggle the solution was to include the older glibc 2.20 with the BC3 files at /usr/lib/beyondcompare.

Moving to glibc 2.24 this no longer works since BC3 is now crashing on startup. If I remove the glibc files from its directory it gets better as there is no longer a crash but I'm back to a very slow startup (5sec or more).

Ideally, a new version of BC3 compiled against newer glib should work fine... Lacking that while I'm able to use the system libqt-mt.so.3 I can't regenerate the C bindings from libqtc.so.1. As far I checked, it is not the version provided with KDE bindings and generated with kalyptus. Could you provide the source code for it or the means of generating this wrapper library?

Thank you,
Mikko

[Aaron]

Hello,

When we last hunted this down, this issue was not specific to all configurations of glibc2.24, since we set up a test machine in the same environment that did not repeat the delay behavior, and have not had other reports since your initial report. Looking up the tracker entry, our developer may have narrowed this down to an 'Infinality' freetype library installed on your system that was buggy and behaving poorly with both BC and glibc. Apologies if you weren't emailed this information. Did you get a chance to remove this font, reboot, and re-test? Please test with BC3 and BC4, if possible.

[mikko]

Looking up the tracker entry, our developer may have narrowed this down to an 'Infinality' freetype library installed on your system that was buggy and behaving poorly with both BC and glibc.

Indeed, Infinality was an issue causing delays but only for BC4.

Apologies if you weren't emailed this information. Did you get a chance to remove this font, reboot, and re-test? Please test with BC3 and BC4, if possible.

There was no need for e-mails, I found that reason myself and updated freetype with a faster version. (please see my 2nd post from 21-Nov-2015 on the "BC4 slow to start..." thread) BC4 did start faster but for my use case it was still overkill and slower than a properly working BC3. It is a pitty Qt4 is so much more demanding at startup compared with Qt3...

I was a happy user of BC3 with the modification I listed before until doing the upgrade to glibc 2.24. BC3 startup delay is not caused by freetype, it is caused by some thread synchronizations being affected by newer versions of glibc. I think those tracing logs are still on the forum. Updating libqtc.so.1 might help and it is the last option I've got left. Unfortunately, it is not the "stadard" open source version provided in the past with KDE bindings. Can you help by opening its source code or a clarification of how it can be rebuilt?

/M

[Aaron]

Hello,

That is actually a little tricky. Due to some licensing we have with the specifically supplied qt library for BC3, it's not something we can wholly provide. Recompiling would also be non-trivial. We'll continue to try and help users run BC3 on legacy systems, but anything using newer libraries is not something we'll be able to help support.

However, I would be very interested in trying to understand how BC4 is continuing to give you trouble after removing the font. Is the machine you are running on particularly old, and just has difficulty running modern graphical applications (reliant on QT4)? Or is there another cause of slowness we can try to troubleshoot? BC4/QT4 is a bit more demanding, but I wouldn't expect to see a vastly different start-up time.

[mikko]

Hello,

Considering the upgrade to BC4 I am quite reluctant to do so since:

a. BC3 had 99.9% of the functionality I used.

b. BC4 needs about 2 sec to start on a 3.07 GHz Xeon X5675, dual processor, 12-core machine from an SSD RAID0 array (or even from memory cache). BC3 was at about 1 sec, still not great but much better in comparison.

c. I don't trust BC4 as much as BC3 due to some harsh errors (one of which I reported in the past and two others I kept silent since I was unsure whether these were not induced by my setup and I was lacking the time to investigate + write the details about them).

d. BC4 (as well as BC3) still lacks updating the X selection when text is selected requiring thus keyboard presses or other mouse clicks for simple text transfers (a "nice to have" feature you mentioned will be considered a year ago).

I already spent half a day with building qtc-0.7a-240.1.3.src.rpm and renaming its functions to match the ones in the binary file only to realize that *SignalHook type of functions are not included and this is not a standard libqtc version. Given the source I'm sure I'll manage in far less time to produce a binary version linked against the latest glibc and qt-3.3.8 if that is too time consuming on your side... (please note it is libqtc wrapper library, not the commercial libqt-mt distributed with BC3!). If the source for libqtc can't be made public I won't be making it public either (given a copy I'll send you back the new binary). Not a guarantee it will solve the slowness but maybe worth a shot...

/M

[Aaron]

Hello,

While BC3 may contain the functionality you use, it requires constant software maintenance in order to run on newer versions of an OS, especially different variations of Linux. BC4's entire core was re-written to be modern and allow it to run on newer Linux and 64bit support. We don't deactivate keys, and you can continue to use BC3 for as long as it works for you, but if you make changes to your OS that break our software (last updated in 2014, but based on core tech older than 2008), then we can't guarantee it will continue to work. Much of BC3 was written with now discontinued technology, which we have had to work extensively to replace for BC4.

BC4's boot up time is about 2 seconds in my test VM, which has far fewer resources available and a mechanical drive. If you roll back to BC 4.0.7 (our last pre-64bit, large patch re-write), does his have a difference in boot time? Please email us at [email protected] with a link back to this post and we can get you a 4.0.7 installer to help troubleshoot this.

We can't help with unreported errors. We understand if you don't have time to help us troubleshoot, but we won't be able to resolve them unless we are able to get a stack trace and a couple sentences describing the steps leading up to the crash. Sometimes we can fix them with that alone. We don't collect any crash information anonymously and our stack trace does not reveal any user workflow information; we're reliant on customer reports to help track down bugs.

If we are able to add X selection behavior, it would need to be the current version of BC; we aren't patching in new behavior into BC3.

I chatted with our developer and they found a link you can use to get the qt3forKylixGen, you can find here:
http://sourceforge.net/project/showf...kage_id=152531
With notes:
- An older version was mainly for Linux (~0.6).
- You would need mono for the .NET code.

It's all quite old code, however, and there is little guarantee you could get it working with BC3. We won't be able to help with recreating this library.

[mikko]

Hi,

Thank you so much for the link! Indeed, that was the library I was looking for and after a little struggle I was able to rebuild it. If of any value for you team I can create and provide a small patch which allows its rebuild with Fedora's qt3.3.8b package. However, to a big disappointment this still did not solve the startup slowness. BC3 behaves exactly the same as with the original version Looks like the thread synchronization primitives that fail are from within the BCompare binary itself. Now I'm out of time for this but if I find something worthwhile I'll write about that latter.

Indeed, I do understand you need to replicate the errors in order to fix them and I also understand that from your perspective there's no incentive at all to recompile BC3 against the latest glibc. I now don't have the time for evaluating BC4.07 or providing test cases that fail. When the X-selection feature will be available my incentive to use BC4 will definitely be stronger In any case I very much appreciate the responsiveness and great level of customer support and thank you again for it!

/M