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