smtk2ssrf_test.AppImage: further testing

Alessandro Volpi volpial at gmail.com
Fri Feb 17 07:04:06 PST 2017


Dear Salva,

I agree that the question of my dive #15 has a bit of "woodo rite" flavor;
nevertheless the explanation is quite simple. I have resumed my diving
activity in 1998, after a 20 years pause. My previous deep diving practice
was based on the type of equipment available in the seventies, namely 4 mm
thick suits, double tanks without SPG and NO BC. So I decided to attend a
course for learning to use the new stuff. I obtained a two stars
Certificate, including rescue procedures, after 15 dives. That's why my
logbook begins with dive #16. When I began to rely on the UWATEC software
for logging my dives, I elected to insert a "fake dive" #15 in order to get
a "template dive" with default values for tanks and suits to be applied to
the new dives being inserted in the log. The advantage of having a fake
dive (formally carried out on 1/1/1900) was simply to be free to change the
defaults for new dives, without being forced to modify the data of a true
dive.
The data in dive #15 include the suit type ( Two pc. wet suit ) an the tank
system ( 2 x 8.5 liter sidemount set ).

I have observed that smtk2ssrf does not consider the template dive to be a
true dive (it is actually fake) and does not export it to the .xml file. I
guess that 1/1/1900 is not a good date; if I have well understood your
program reads it as 1/1/2000 , exactly one century later !

Coming back to the issue of the .AppImage executables I point out that,
theoretically, a computer program should ALWAYS BEHAVE THE SAME WAY with
the same input data, unless the program gets entropy from a source like
/dev/urandom . I mean that a program which is crashing once with a
<SEGMENTATION FAULT> SHOULD ALWAYS CRASH WITH THE INSTRUCTION POINTER VALUE
ALWAYS POINTING TO THE SAME INSTRUCTION. Moreover the program should always
read the SAME  stuff ( right or wrong) in all records, including record
#15. I do not understand why this record seems not to be as good as any
other...

Apparently IT IS NOT ... and I cannot imagine how this could happen. I am
not familiar with AppImage building procedures and I read on your message
that you are not also completely at ease with that.

Btw I have yesterday tried to run a Subsurface AppImage on Fedora 24. The
program was working in spite of some complains about wrong libraries and
 in spite of some problem probably related to the application fonts. I
fully agree with you that the AppImage approach is somehow tricky. I guess
that the question is much more complicated than simply including
stand-alone instances of some shared libraries  in the executable ...

As far as the test of subsurface build scripts on Ubuntu xenial,  is
concerned, I must admit that I was not able to carry it out as promised.
This has been a busy week for me and I was forced to lend my laptop with
xenial to a friend of mine. She is complaining since I have not yet
finished to install Linux on her new PC and she needs a working computer
right now. I hope to be able to complete the job next week, so that I can
get back my laptop ...

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/20170217/f525558f/attachment-0001.html>


More information about the subsurface mailing list