Fossil

View Ticket
Login

View Ticket

Ticket Hash: 2ee159304e721349aae20e7a8155c7e6c2b041a9
Title: Error in timeline (armv5tel-linux) showing events
Status: Open Type: Code_Defect
Severity: Priority:
Subsystem: Resolution: Open
Last Modified: 2011-05-13 16:08:19
Version Found In: [cf178577ec]
Description:
This comes from further investigating of the problem quite bad reported at [f1c75f3844687].

I got confused again when I said it was about time (I missed one unsynched local 'fossil ui' with the server).

So, as said, you can clone that repository: http://vicerveza.homeunix.net/~viric/cgi-bin/nanonixos
You will see in the timeline of the server that the event related to the artifact 4d12cabdeca86a71190c39b1e458faae4fad0faf does not appear in the timeline. But I imagine it will appear in your local fossil timeline.

I've investigated a bit...

That server (vicerveza.homeunix.net) running fossil as a cgi is an armv5tel-linux. I tried there fossil [cf178577ec] 2010-11-17 and fossil [12a79e5b93] 2010-10-05). Both show the same behaviour: the event of that artifact is not shown in the timeline. I've tried in all the cases a 'rebuild'.

Nevertheless, if I clone that in an x86_64-linux, I don't have any problem in the local 'fossil ui', using the [cf178577ec] 2010-11-17 version.

The server, to give more details, has gcc 4.5.1, glibc 2.12.1, and all fossil tests passed after building.

<hr /><i>anonymous claiming to be viric added on 2010-11-30 19:40:51:</i><br />
As long as investigate...
I'm trying "fossil sqlite3". There should be three events, and for example I get:
<verbatim>
sqlite> SELECT * from event WHERE event.type='e';
e|2455530.46353009|168|19||||viric||The malta keyboard does not work still|
e|2455530.49096065|169|20||||viric||links2 not working in graphics mode|
</verbatim>


<hr /><i>anonymous claiming to be viric added on 2010-11-30 20:06:55:</i><br />
I've just compared de "rebuild -quiet -sqltrace" both in x86_64 and armv5tel. The concerning block with the difference is:
<verbatim>
282,283c285,288
< SELECT rid FROM tagxref WHERE tagid=11 AND mtime<2455525.422407407 ORDER BY mtime DESC;
< SELECT rid FROM tagxref WHERE tagid=11 AND mtime>2455525.422407407 ORDER BY mtime;
---
> SELECT rid FROM tagxref WHERE tagid=11 AND mtime<2455525.422407408 ORDER BY mtime DESC;
> DELETE FROM event WHERE type='e'   AND tagid=11   AND objid IN (SELECT rid FROM tagxref WHERE tagid=11);
> SELECT rid FROM tagxref WHERE tagid=11 AND mtime>2455525.422407408 ORDER BY mtime;
> REPLACE INTO event(type,mtime,objid,tagid,user,comment,bgcolor)VALUES('e',2455525.421157408,74,11,'viric','Nanonote boot',  (SELECT value FROM tagxref WHERE tagid=1 AND rid=74));
</verbatim>

I think there may be a problem on floating point precision / algorithms. The armv5tel cpu does not have a FPU, and it uses gcc's -msoft-float.

<hr /><i>anonymous claiming to be viric added on 2010-11-30 20:33:57:</i><br />
So, manifest_parse includes:
<verbatim>
        p->rDate = db_double(0.0, "SELECT julianday(%Q)", next_token(&x,0));
</verbatim>

While the tag_insert called in manifest_crosslink() does:
<verbatim>
  db_prepare(&s,
    "REPLACE INTO tagxref(tagid,tagtype,srcId,origid,value,mtime,rid)"
    " VALUES(%d,%d,%d,%d,%Q,:mtime,%d)",
    tagid, tagtype, srcId, rid, zValue, rid
  );
  db_bind_double(&s, ":mtime", mtime);
</verbatim>

While the call at manifest_crosslink() does:
<verbatim>
    prior = db_int(0,
      "SELECT rid FROM tagxref"
      " WHERE tagid=%d AND mtime<%.17g"
      " ORDER BY mtime DESC",
      tagid, p->rDate
    );
</verbatim>

I think that the <tt>%.17g</tt> printf kind of prompt should be moved into db_bind_double, as before. Otherwise there may be rounding problems, like those I am experiencing.

Notice that the tag_insert resulted, in both computers, in:
<verbatim>
REPLACE INTO tagxref(tagid,tagtype,srcId,origid,value,mtime,rid) VALUES(11,1,74,74,'365',2455525.42240741,74);
</verbatim>

While the printf-style SQL queries with <tt>%.17g</tt> had different results in the two computers.

<hr /><i>anonymous claiming to be viric added on 2011-01-10 08:20:18 UTC:</i><br />
Is [722d7cac97] going to mean any improvement on this?

Thank you.

<hr /><i>viriketo added on 2011-05-13 16:08:19 UTC:</i><br />
I think [9b26d1e9a2] may have fixed the problem. I'll try.