On 2015-09-22 03:58 PM, Hugues Bruant wrote:
> On Tue, Sep 22, 2015 at 6:22 AM, Richard Hipp <drh at sqlite.org> wrote:
>
>> On 9/22/15, Hugues Bruant <hugues at aerofs.com> wrote:
>>>> If you can capture a malfunctioning trace, and send in the database
>>>> file and the SQL statement that is running, that should allow us to
>>>> localize the problem.
>>>>
>>> Trace for the failing UPDATE:
>>>
>>> cv_s=1
>> The trace shows that you have this value set to 0, not 1.  And
>> apparently there is no row with cv_s=0 and cv_o=b8b9f4...
>>
> That is rather curious.
>
> The method where the UPDATE fails is as follows:
>
> public void setVersion_(SIndex sidx, OID oid, long version, Trans t) throws
> SQLException
> {
>      try (Statement s = c().createStatement()) {
>          s.execute("pragma vdbe_debug=ON");
>      }
>      int n = exec(_pswSetVersion, ps -> {
>          ps.setLong(1, version);
>          ps.setInt(2, sidx.getInt());
>          ps.setBytes(3, oid.getBytes());
>          return ps.executeUpdate();
>      });
>      try (Statement s = c().createStatement()) {
>          s.execute("pragma vdbe_debug=OFF");
>      }
>      if (n == 1) return;
>      if (version > 1) {
>          l.warn("{}{} {} {} {}", sidx, oid, version, getVersion_(sidx, oid),
> n);
>      }
>      exec(_pswInsertVersion, ps -> {
>          ps.setInt(1, sidx.getInt());
>          ps.setBytes(2, oid.getBytes());
>          ps.setLong(3, version);
>          checkState(ps.executeUpdate() == 1);
>          return null;
>      });
> }
>
> SIndex sidx is just a boxed immutable integer. Its value is bound to the
> UPDATE and the trace shows it to be 0
> But the log line printed when the number of rows updated is zero clearly
> shows the value to be 1 and this is further
> confirmed by the fact that when bound to the INSERT, the value turns out to
> be 1 (or there would be no constraint
> violation).
>
> This leaves essentially two places for the error to arise:
>   - sqlite3_bind_int
>   - somewhere in the JVM
>
> I will add more logging and see if I can pinpoint the location where the
> (incorrect) 0 value appears.

That does look a bit like magic - and as is 99.9% the case when 
inexplicable magic happens, memory is getting corrupt or overwritten. 
You are obviously prudent about this, but is there no clue when running 
under Valgrind or similar for OSX? Nothing out of the ordinary or warnings?

(I'm unfortunately not strong on the JAVA VM, so another approach might 
be needed to achieve the checking...)
Ryan

Reply via email to