smtk2ssrf_test.AppImage: further testing

[Alessandro Volpi]

Hi, Salva.

Yesterday I was able to do some testing on my xenial laptop.

I have launched the smtk2 Appimage 10 times, with the same input file
dive_log.slg . Such file is almost equal to its previous version.  The only
differences are the date of the first dive in the log ( #15 .. the "fake"
dive used as template for new dives in SmartTrak) and the correction of
some misspellings in the notes section of several dives.

The terminal output of the first 2 trials has been copied to
file smtk2_error.txt. The first trial resulted, as expected, in an output
file named trial1.xml . The second trial, started a few minutes later,
produced an application CRASH.
Nothing was changed in the meantime ...

The other 8 trials produced an output file, from trial2.xml to trial9.xml .

I have checked with diff that trials 1 , 2 , 3  4 , 5 , 7 , 8 produced
identical output file. So I have deleted all these files with exception for
trial1.xml.

Trial 6 is affected by an error on dive #415: <suit>Tank 15 liter
Steel</suit> ; see the difference file diff_1_6.txt ; once more dive #415
IS SOMEHOW different.

Trial 9 is affected by an error in dive #416 :
<suit>9,1676000000000002e+00</suit>
; see the difference file diff_1_9.txt ; it is the first time I observe an
error in a dive other than dive #415.

The above mentioned files can be found in subdirectory testing_on_xenial in
my Dropbox folder at URL :

https://www.dropbox.com/sh/cvtjbg6n5f4dmfy/AADSUdZPgjbPtWil57JWKOOla?dl=0

What is VERY UNUSUAL about the smtk2 AppImage is the fact that it produces
different results with the same input file. This is in principle not
possible for a deterministic procedure. I therefore guess that the
application is not a single process but is indeed the result of of the
cooperation of more than one process. I have in the past observed random
errors in applications consisting in more than one process. The cause was
always a problem of synchronization of the different processes, so that the
results were depending on the machine' s workload. Management of signals
and mutexes was the key for fixing the bug.

As soon as I succeed in building smtk2 as a regular application I will
check whether the issue is related to the use of AppImage or in somehow
intrinsic in the application or in Qt5.

Very best regards.

Alessandro

On Thu, Feb 16, 2017 at 11:47 PM, Salvador Cuñat <salvador.cunat at gmail.com>
wrote:

> Good night Alessandro, thank you very much for such a detailed testing.
>
> On Wed, Feb 15, 2017 at 11:14:08PM +0000, Alessandro Volpi wrote:
> > I have tested two versions of the AppImage on Fedora 24 (64bit)
> >
> >
> >    1. [~/bin]$file smtk2ssrf_test.AppImage :: smtk2ssrf_test.AppImage:
> ELF
> >    64-bit LSB executable, x86-64, version 1, dynamically linked,
> interpreter
> >    /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18,
> >    BuildID[sha1]=30434935ca0d1a94a0eb2853b71390dfe2e9017f, stripped
> >    2. [~/myfiles/downloads]$file smtk2ssrf_test.AppImage ::
> >    smtk2ssrf_test.AppImage: ELF 64-bit LSB executable, x86-64, version 1,
> >    dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux
> >    2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d,
> stripped
> >
> > The two .AppImage file will be briefly indicated as "old" (1.)  and "new"
> > (2.) in the following text.
> >
> > First trial:
> >
> > The old AppImage was launched from a terminal, relying on the GUI. The
> > resulting files are:
> > smtk2_old_gui_out.txt, containing the output on the terminal
> > smtk2_old_gui_log.txt , containing the program's output on the GUI
> window.
> > smtk2_old_gui.xml , the input file for subsurface
> >
> > Second trial :
> >
> > The old AppImage was launched from the terminal indicating input and
> output
> > file as command arguments. The resulting files are:
> > smtk2_old_out.txt, containing the output on the terminal
> > smtk2_old.xml , the input file for subsurface
> >
> > Third trial :
> >
> > The new AppImage was launched from the terminal indicating input and
> output
> > file as command arguments. The resulting files are:
> > smtk2_new_out.txt, containing the output on the terminal
> > smtk2_new.xml , the input file for subsurface
> >
> > Fourth trial :
> >
> > The new AppImage was launched from a terminal, relying on the GUI. The
> > resulting files are:
> > smtk2_new_gui_out.txt, containing the output on the terminal
> > smtk2_new_gui_log.txt , containing the program's output on the GUI
> window.
> > smtk2_new_gui.xml , the input file for subsurface
> >
> > After examining the four .xml files I found out that three of them are
> > identical. The different file is smtk2_old. The only different record is
> > dive 415, where the notes were not correctly read. It is worth while to
> > point out that dive 415 was manually inserted in SmartTrak, since no
> UWATEC
> > dive computer was used for the dive. On the other hand this is not the
> only
> > dive manually inserted; it is simply the only dive where an error has
> been
> > ascertained.
> I can see the difference between both xml files, but I don't really
> understand the reason for it. I've runned 7 different versions
> (appimages and builds from sources) on your slg file and #415's notes
> are always readed.
> >
> > Another unexpected behavior is that the new AppImage, when launched in
> GUI
> > mode complains about missing libGL components. On the other hand dnf says
> > that required packages are installed and latest version. This might be
> > related to the nvidia proprietary drivers. In spite of the allegedly
> > missing components the program seems to run flawlessly. Moreover I do not
> > understand why libGL should be required for a 2D graphic application such
> > as smtk2ssrf .
> >
> I don't think this is appimage related, I'd put my money on Qt.
>
> > Another even more surprising event was a SEGMENTATION FAULT crash when i
> > tried to launch the new AppImage as  command line application (see file
> > smtk2_new_out.txt). I tried to do that a second time and the program ran
> > flawlessly.
> >
> This seems libmdb related. Never saw it before, not in my old 32b
> laptop nor my 64b one.
>
> > I do not know anything about the behavior of .AppImage executables, but
> is
> > was apparent that, running 2 times with same input file may result in
> > different output file; moreover I was not sure that the different result
> > was actually dependent on the sunning condition, command line or GUI.
> >
> > I have thus run once again the "Second trial"; surprisingly the resulting
> > file smtk2_old_2.xml is not equal to smtk2_old.xml but is identical to
> the
> > .xml files obtained in trials 1, 3 , 4 ; the question of the GUI is not
> in
> > my opinion relevant.
> >
> > I have also tested the new AppImage on my laptop, with a freshly
> installed
> > Ubuntu xenial OS.
> >
> > I have not saved the files, but I can tell you that, also with xenial I
> > have got different .xml files running the AppImage more than once.
> >
> > My conclusion is that, SOMEHOW, RUNNING THE APPLICATION WITH THE SAME
> INPUT
> > MAY RESULT IN DIFFERENT .XML FILES, DEPENDING ON SOME EXTERNAL
> DISTURBANCE.
> > THE ERROR IS ALWAYS IN THE NOTES OF DIVE 415 !
> > i CANNOT IMAGINE HOW THAT COULD HAPPEN ... I begin doubting about
> AppImage
> > "relocatability" ...
> >
> I can't agree with you on this. I'm actually using suburface 4.6.0
> appimage without any issue. This problems seems to be more related to
> my own inability to produce a stable appimage.
> I love it's philosophy, but libraries management through different
> distros is a true pain.
>
> BTW, I'm seeing in all produced divelogs (also in slg file) a dive
> numbered #15, which seems to lack of date and time (well it claims to
> be 01-01-2000 at 00:00:00) and any other info but the suit.  Is it
> correct or some kind of weird artifact from the Access database?
>
> And finally, have you tried to build from sources on Xenial?
>
> Again, thanks for your heavy testing.
>
> Best regards.
>
> Salva.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170219/bd9fe60c/attachment.html>