i can imagine this. As i wrote earlier to you the dives were imported from severeal different applications - DataTrak, Wlog, SmartTrak and DiverLog for Oceanic and manually added. Don't know which fields were importable which not and if all fields were mapped correctly.
best regards
Manfred
On 15.08.2020 07:48, Salvador Cuñat
wrote:
Hellow.
The morning coffee seems to trigger my imagination and I think I've got it.The data in cloud storage seems to be screwed badly for some reason. It shows some dives lasting 500hr or more and other inconsistencies ... Most of this dives are pretty old, while newer are correct, so neither Manfred nor me realized it before.
Fortunately looks like the divelog can be manually fixed and I'll try to this evening.
If the event issue is still there after the fix, I'll report it again.
Best regards.
Salva.
El vie., 14 ago. 2020 a las 23:37, Linus Torvalds (<torva...@linux-foundation.org>) escribió:
On Fri, Aug 14, 2020 at 1:55 PM Salvador Cuñat <salvador.cu...@gmail.com> wrote:
>
> Dive num = 394 -- ev type = 11
> ev->gas,index = 1
> Dive num = 398 -- ev type = 11
> ev->gas,index = 1
> Dive num = 401 -- ev type = 25
> ev->gas,index = 0
> Dive num = 401 -- ev type = 6
> Dive num = 401 -- ev type = 3
> Dive num = 401 -- ev type = 3
> Dive num = 401 -- ev type = 3
> Dive num = 401 -- ev type = 6
> Dive num = 401 -- ev type = 25
> ev->gas,index = 270305728
> Violación de segmento
>
> You were right, off course Dirk, look at the last line before the segfault.
> I've pasted the previous lines because they are wrong too ... Dive 401 has just a single event type 25, following events are wrong and, most probably come from following dives.
Ok, so the first ev type = 25 looks sane, with a gas index of zero.
And the other events are goarbage and don't show up in the wlog data?
ev type = 3 is ascent warning, and type 6 is some transmitter warning
(SAMPLE_EVENT_TRANSMITTER?)
> Yes, seems completely random.
That SAMPLE_EVENT_TRANSMITTER looks odd too. I've never seen it, but
who knows. Might be some odd translation artifact, but it does exist
in the uwatec_memomouse_parser, so maybe it's real.
Is there any way we could reproduce this locally?
But another thing you could try is to just run your load under
valgrind. That might pinpoint the problem..
Linus
-- Manfred Hantl Helga-Seibert-Str. 41 76149 Karlsruhe Telefon +49 721 46726072 Mobil +49 171 2217468
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
