On Mon, Oct 8, 2012 at 10:54 AM, Matthew Dumbleton <msd...@hotmail.com>wrote:
> So does this mean therefore SQLite will not currently work on a compact
> framework device? (Or at least not on mine.)
> There's nothing else installed or running apart from the test app I sent
> you using SQLite and the OS itself. That dll is protected inside the
> windows directory on the device so I cannot even
> try removing/renaming it.
> Since the device isn't crashing on it's own it's presumably some sort of
> inadvertant call being made as part of the application running, which
> disappears when SQLite is not referenced.
> And since Microsoft aren't likely to release any updates to the compact
> framework I'm not sure where to go with this.
>
> > From: sql...@mistachkin.com
> > To: sqlite-users@sqlite.org
> > Date: Mon, 8 Oct 2012 06:00:50 -0700
> > Subject: Re: [sqlite] Seemingly random Access violation errors (resent)
> >
> >
> > Matthew Dumbleton wrote:
> > >
> > > Sorry about that. Sent you the attachments properly a while ago and
> have
> > > also just sent you a .txt file with the last output from the debugger
> > > before the access violation crash thanks to your new version.
> > >
> >
> > The start of the trouble seems to be here:
> >
> > Data Abort: Thread=8aeec800 Proc=81a374c0 'SQLiteDatabaseEngineTest.exe'
> > AKY=00010001 PC=7b38a890(netcfagl3_5.dll+0x0000d890)
> > RA=7b38a7d0(netcfagl3_5.dll+0x0000d7d0) BVA=11000000 FSR=00000005
> > #$# Exception 0xC0000005 <SQLiteDatabaseEngineTest.exe>
> > #$# Thread procedure: rtlogshimeng.dll!0x000744C8 (in dll)
> > #$# PC: netcfagl3_5.dll!0x0000D890 (in dll)
> > #$# Return address: netcfagl3_5.dll!0x0000D7D0 (in dll)
> > #$# Call stack top
> >
> > This exception appears to be coming from the .NET Compact Framework
> itself
> > on a thread calling into the rtlogshimeng DLL (I'm not sure what this DLL
> > is for).
> >
> > Later on in the debugger output, I see:
> >
> > *** ASSERTION FAILED in ../core/sqlite3.c(15799):
> > pInt[nReserve/sizeof(int)]==(int)0xE4676B53
> >
> > This type of assertion failure indicates generalized heap corruption.
> > After this, nothing in the heap can truly be trusted.
> >
> > --
> > Joe Mistachkin
Are you having this problem with a Motorola device?
--
--
--
--Ô¿Ô--
K e V i N
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
