Re: stuck in deco calculations

2015-09-20 Thread Robert Helling 
Hi,

> On 20 Sep 2015, at 07:46, Dirk Hohndel  wrote:
> 
> But regardless how much I stare at this, I can't see why we have entries
> for 2005 and then 1996, so 33:25 and then 33:16.
> 
> The Uemis contains a sample at 33:25, but none at 33:16. And this happens
> when switching to the Atomics. So... hu???

I figured that what is special about 33:16 is that there is a sample with 0 
depth at 33:17. When I delete all 0 depth samples from the Uemis, the problem 
goes away. My guess (so far unconfirmed is that some part of the code uses 0 
depth as some kind of in band signalling…).

Best
Robert


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: stuck in deco calculations

2015-09-20 Thread Robert Helling 
Hi,

> On 20 Sep 2015, at 08:30, Robert Helling  wrote:
> 
> 
> I figured that what is special about 33:16 is that there is a sample with 0 
> depth at 33:17. When I delete all 0 depth samples from the Uemis, the problem 
> goes away. My guess (so far unconfirmed is that some part of the code uses 0 
> depth as some kind of in band signalling…).
> 

it is related to profile.c lines 497ff:

if ((depth > SURFACE_THRESHOLD || lastdepth > 
SURFACE_THRESHOLD) &&
s->time.seconds > maxtime)
maxtime = s->time.seconds;


If I comment out the if so that maxtime is assigned unconditionally, the 
problem goes away (but of course some 0 depth is displayed at the end).

Have to go now.

Best
Robert


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: stuck in deco calculations

2015-09-20 Thread Linus Torvalds 
On Sat, Sep 19, 2015 at 10:46 PM, Dirk Hohndel  wrote:
>
> A silly patch like this prevents the hang, but I really want to understand
> why we end up with two consecutive entries that have non-monotonous time
> stamps...

So we've done something slightly odd.

Your XML file has these samples:

  ^M
  ^M

and those are correct in the sample array:

(gdb) p dc->sample[132]
$20 = {time = {seconds = 1995}, stoptime = {seconds = 0}, ndl =
{seconds = 11940}, tts = {seconds = 0}, rbt = {seconds = 0}, depth =
{mm = 517}, stopdepth = {mm = 0}, temperature = {mkelvin = 0},
  cylinderpressure = {mbar = 94320}, o2cylinderpressure = {mbar = 0},
setpoint = {mbar = 0}, o2sensor = {{mbar = 0}, {mbar = 0}, {mbar =
0}}, bearing = {degrees = 0}, sensor = 0 '\000',
  cns = 0 '\000', heartbeat = 0 '\000', sac = {mliter = 0}, in_deco =
false, manually_entered = false}
(gdb) p dc->sample[133]
$21 = {time = {seconds = 2010}, stoptime = {seconds = 0}, ndl =
{seconds = 11940}, tts = {seconds = 0}, rbt = {seconds = 0}, depth =
{mm = 557}, stopdepth = {mm = 0}, temperature = {mkelvin = 0},
  cylinderpressure = {mbar = 94596}, o2cylinderpressure = {mbar = 0},
setpoint = {mbar = 0}, o2sensor = {{mbar = 0}, {mbar = 0}, {mbar =
0}}, bearing = {degrees = 0}, sensor = 0 '\000',
  cns = 0 '\000', heartbeat = 0 '\000', sac = {mliter = 0}, in_deco =
false, manually_entered = false}

but the plot-info (which expands the samples to have a maximum of 10s
intervals, and inserts events etc) has

  (gdb) p pi->entry[267]
  $32 = {in_deco = 0, cylinderindex = 0, sec = 1995, pressure =
{94320, 0}, o2cylinderpressure = {0, 0}, temperature = 291483, depth =
517, ceiling = 0, ceilings = {0 }, percentages = {
  (gdb) p pi->entry[268]
  $33 = {in_deco = 0, cylinderindex = 0, sec = 2005, pressure =
{94320, 0}, o2cylinderpressure = {0, 0}, temperature = 291483, depth =
544, ceiling = 0, ceilings = {0 }, percentages = {
  (gdb) p pi->entry[269]
  $34 = {in_deco = 0, cylinderindex = 0, sec = 1996, pressure =
{94320, 0}, o2cylinderpressure = {0, 0}, temperature = 0, depth = 0,
ceiling = 0, ceilings = {0 }, percentages = {
  (gdb) p pi->entry[270]
  $35 = {in_deco = 0, cylinderindex = 0, sec = 1997, pressure =
{94320, 0}, o2cylinderpressure = {0, 0}, temperature = 0, depth = 0,
ceiling = 0, ceilings = {0 }, percentages = {

at this point. Note how "2010" (33:30) is missing entirely - the 2005
one is the "ten seconds after 1995" (33:15 + 10 = 33:25).

And "pi->nr" is 271 so the above is the very end of the plot-info array.

Note how the *sample* array is bigger, and dc->samples is 137, so
those samples 132/133 are *not* at the end of the sample array. So the
two last events look like the two surface events we populate (and I
think that explains the "+1", but where are the rest of the events?

So it looks like "populate_plot_entries()" has done something wrong.

Looking further, it looks like "pi->maxtime" is 2008 (33:28min). And
that seems to be what screws "populate_plot_entries()" up: it depends
on maxtime for deciding on number of allocations, and it also has

if (time > maxtime)
break;

and stops populating the plot-info entries there. And because the
interpolated entries (ie entry 2005) are inserted specially, we hadn't
updated "lasttime", so time went backwards.

So this bug is due to several oddities:

 - INSERT_ENTRY() doesn't update lasttime, so if the last entry is an
INSERT_ENTRY, we get confused at the final surface events we insert

   And no, we mustn't update lasttime in INSERT_ENTRY, because we
actually want to have it match "lastdepth".

 - the (time > maxtime) breakout thus results in us crating incorrect
entries at the end.

 - but that "time > maxtime" breakout doesn't make sense to begin with

 - HOWEVER -  we *do* use maxtime to estimate the size of the
allocation, so 

And the reason "maxtime" is smaller than the last offset is that the
end of that dive has depths that are shallower than SURFACE_THRESHOLD.

Anyway, the quick fix is to move that exit condition (the "if (time >
maxtime) break;') because that really does screw things up in the
place it is now. Moving it to the *end* of the for-loop guarantees
that we've fixed up "lasttime" and "lastdepth" correctly, but it also
means that we may have one entry that is past maxtime in the plot
info, so change the plot-info allocation to have one more slop entry.

So try the attached patch, and if it works for you, commit it with my
sign-off (and try to munge the above explanation into a commit
message).

Linus
 profile.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/profile.c b/profile.c
index b676dc5b002f..cad768728b74 100644
--- a/profile.c
+++ b/profile.c
@@ -551,9 +551,11 @@ struct plot_data *populate_plot_entries(struct dive *dive, 
struct divecomputer *
 * but samples could be more dense than that (so add in dc->samples). 
We also
 * need to have one

Re: stuck in deco calculations

2015-09-19 Thread Dirk Hohndel 
Sorry, had an invalid address for Robert...

On Sat, Sep 19, 2015 at 10:29:22PM -0700, Dirk Hohndel wrote:
> So I tested the Uemis download with force and retry and a couple of
> iterations of that... it all looked good. And then I accepted the download
> and Subsurface hung. Attached a debugger and it's clearly hung in deco
> calculations. Specifically, and that's what's puzzling me, in
> calc_crushing_pressure(). Since we don't use vpm-b for displaying the
> ceiling of recorded dives, I of course wonder why this code is ever called
> - and it is, unconditionally, in add_segment().
> 
> Robert, any comment on this?
> 
> I'd love to try and save a test file that allows one to reproduce the
> issue, except that I can't seem to get to a point where I could save the
> dive file. The deco computation appears to finish eventually, only to get
> started again :-(
> 
> As I tried to debug this more in the running process, looking around I
> notice that I'm in calculate_deco_information() with a time_stepsize of -9
> (hmm, that's fascinating) and a depth of -2147483648... that's not good.
> 
> Digging deeper shows me that have two consecutive plot entries where the
> first one has a time stamp that's larger than the second one which messes
> up everything else.
> 
> I'll continue to try to trick Subsurface in the debugger to let me save
> the data file. This one is annoying :-(

I managed to save this and can reproduce the problem, but I don't
understand it.

A silly patch like this prevents the hang, but I really want to understand
why we end up with two consecutive entries that have non-monotonous time
stamps...

diff --git a/profile.c b/profile.c
index 158517e2deae..b676dc5b002f 100644
--- a/profile.c
+++ b/profile.c
@@ -849,6 +849,12 @@ void calculate_deco_information(struct dive *dive, struct 
divecomputer *dc, stru
 
(prefs.gflow - prefs.gfhigh) +
 prefs.gfhigh) *
(100.0 - AMB_PERCENTAGE) / 100.0 + 
AMB_PERCENTAGE;
+   if (t0 > t1) {
+   fprintf(stderr, "non-monotonous dive stamps %d %d\n", 
t0, t1);
+   int xchg = t1;
+   t1 = t0;
+   t0 = xchg;
+   }
if (t0 != t1 && t1 - t0 < time_stepsize)
time_stepsize = t1 - t0;
for (j = t0 + time_stepsize; j <= t1; j += time_stepsize) {

Attached is an XML file with just the one dive. Switching to the second
dive computer triggers the problem for me.

If you look at the XML it's clear that forcing the download from the Uemis
again caused a weird merge - Linus pointed out that something fishy was
happening there.

But regardless how much I stare at this, I can't see why we have entries
for 2005 and then 1996, so 33:25 and then 33:16.

The Uemis contains a sample at 33:25, but none at 33:16. And this happens
when switching to the Atomics. So... hu???

Clearly I'm missing something. Can someone else try to poke at this?
Yes, we need to fix the merge issue, but this second problem should be
unrelated because what I have here is (I think) a valid XML file...

/D




  












  Ethan
  Some notes
  (dry, Whites Fusion, Weezle) or (wetsuit 2-3mm)

Re: stuck in deco calculations

2015-09-19 Thread Robert C. Helling 
Good morning,On 20 Sep 2015, at 07:29, Dirk Hohndel  wrote:Robert, any comment on this?just got out of bed, before the first coffee. This patch prevents the deco calculation (which takes a lot of time) but of course does not help with the original problem. Hope to have some time for that later.BestRobertFrom 22290842927a1e1c716f4dc86f88fcde4e03c232 Mon Sep 17 00:00:00 2001
From: "Robert C. Helling" 
Date: Sun, 20 Sep 2015 07:52:14 +0200
Subject: [PATCH] Only calculate crushing pressure in VPM-B mode

Don't do this expensive calculation when not needed.

Signed-off-by: Robert C. Helling 
---
 deco.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/deco.c b/deco.c
index ec4501b..39a6b34 100644
--- a/deco.c
+++ b/deco.c
@@ -511,7 +511,8 @@ void add_segment(double pressure, const struct gasmix 
*gasmix, int period_in_sec
tissue_n2_sat[ci] += n2_satmult * pn2_oversat * n2_f;
tissue_he_sat[ci] += he_satmult * phe_oversat * he_f;
}
-   calc_crushing_pressure(pressure);
+   if(prefs.deco_mode == VPMB && in_planner())
+   calc_crushing_pressure(pressure);
return;
 }
 
-- 
1.9.5 (Apple Git-50.3)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface