subsurface crash when merging .xml files

Alessandro Volpi volpial at gmail.com
Sat Feb 18 15:58:53 PST 2017


Good night, everyone.

Today I have tested the patched version (AppImage) of subsurface.

I began creating a new file:  complete_2.xml ; the file is almost equal to
dive log used in my first message dated 16/02/2017 . 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.

File first_482_2.xml was obtained from complete_2.xml by deleting dives
from #483 to #501. I have checked the differences between the two files
and, as expected, no differences have been detected other than the missing
dives.

I ran subsurface once again, opening file first_482_2.xml and importing
file complete_2.xml over it. The patched program DID NOT CRASH as the merge
operation was performed. THIS IS GOOD NEWS, albeit not unexpected. The
resulting log is file complete_3.xml .

I compared files complete_2.xml and complete_3.xml :
( diff -y -W 200 /home/ale/myfiles/Dropbox/subs
urface_testing/dive_log_xenial/complete_2.xml  /home/ale/myfiles/Dropbox/sub
surface_testing/dive_log_xenial/complete_3.xml > diff_2_3 ).

In my opinion there is still something to be fixed in the merge procedure.
Files complete_2 and complete_3 should be identical, since I would expect
the merge operation to ignore the content of existing dives fro #15 to #482
and simply to add the deleted dives once again.

Looking into file diff_2_3 I have observed the following two unexpected
behaviors:

   1. The records related to dive site description have been DUPLICATED
   2. A large number of strings like <divetemperature air='0.0 C'
   water='20.0 C'/> has been replaced with <divetemperature air='0.0 C'/>;
   this happened in all dives imported from the old Aladin Air Z, on a few
   dives logged from the newer SmartTec and with ALL MANUALLY INSERTED DIVES,
   where air and water "divetemperature" values are obviously set to 0.0 C .
   In any case I would expect not to find any difference in such records
   before and after the merge operation, since, as I have already said, the
   merge operation should import ONLY NEW DIVES and leave the existing dives
   UNCHANGED. Dives logged from the new Galileo Trimix seem to be unaffected.

The problem about the deletion of the water temperature data is NOT in my
opinion very important. The issue of dive site information being duplicated
is more serious, if the user decides to repeatedly import new dives from
SmartTrak logs and the new dives have been carried out in previously
registered dive sites.

This is now even more important since I HAVE FOUND A BUG in the irda-utils
package. This is NOT RELATED to subsurface development, but is a problem
for all users of UWATEC devices with IR USB adapter (MCS7780).

I remember that I had some years go tried to replace SmartTrak with Jtrak,
a Java application recommended by UWATEC. I was not satisfied with JTrak,
but the irda interface was perfectly working under an old Fedora version.

Such irda interface is BROKEN in the new Fedora releases and the package
maintainers are not at present able to suggest how the bug could be fixed.
The irda-utils project has not been updated since 2011,

The irda interface works perfectly in Ubuntu trusty, but is BROKEN in
Ubuntu xenial. I might be wrong, but my feeling is that the change from
upstart to systemd is the explanation for the failure to start the irda
service when the OS is booted. I am not saying that systemd is not good, I
am just saying  that irda-utils needs new configuration files for systemd
and that my trials to write such files have been up to now  definitely
unsuccessful due to my apparent lack of knowledge about irda-utils and
systemd.

As far as subsurface users are concerned, I am inclined to think that it
will not be possible to get a working irda service in a short time. At
present the only practical solution is repeatedly importing data from
SmartTrack .

All the mentioned files can be found in folder in subdirectory
 dive_log_xenial  on https://www.dropbox.com/sh/dsg
43qcbo013i1k/AAC_vCS3cZeZar5i3HngCNq3a?dl=0

Very best regards.


Alessandro



On Thu, Feb 16, 2017 at 5:02 PM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

> On Thu, Feb 16, 2017 at 8:40 AM, Alessandro Volpi <volpial at gmail.com>
> wrote:
> > I have reported the bug at 00:25 UTC.  You have located the bug and
> released
> > the patch at 01:10 UTC !
> >
> > I have never seen something like that in my life  ... and I am 64 years
> old
>
> Don't get _too_ used to it. It doesn't always work quite that well -
> and not just because the developers may end up being busy doing other
> things.
>
> What really helped was that you had a good report and a repeatable
> test-case that you made available so that developers could trivially
> reproduce the problem.
>
> The bugs are much harder to fix when they aren't that well-behaved and
> the bug reports aren't so clear. So you should take credit for making
> it easy to fix.
>
> And obviously it would be good if you can also verify that everything
> else looks good after the merge with the new daily build.
>
> And as I wrote that, I just realized that I don't even know if there
> are daily Appimage builds - they're not in the downloads/daily
> directory.  Dirk, where do you put them these days?
>
>             Linus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170218/0ffc9294/attachment.html>


More information about the subsurface mailing list