Hi, again,
I did recompile everything with /MDd and I did fix couple of issues.
However the crash is back and below is the (full) stack trace:
()
>sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p) Line 19996 + 0xc bytes
> C
sqlite.dll!sqlite3Close(sqlite3 * db, int
> Le 31 janv. 2016 ? 18:06, Igor Korot a ?crit :
>
> Ok, I did try to recompile everything with /MDd.
> The crash again happens only on the main frame destruction.
> Everything worked after the pointer had been assigned to the main frame
> member.
> I don't understand this at all.
>
> Thank
Teg,
On Sun, Jan 31, 2016 at 12:29 AM, Igor Korot wrote:
> Teg,
>
> On Sat, Jan 30, 2016 at 1:54 PM, Teg wrote:
>> Hello Igor,
>
> This is all compiling with /MTd.
>
>>
>> I might set a break point in the destructor for the DB class and make
>> sure it's not being fired before the exit crash.
Clemens,
On Fri, Jan 29, 2016 at 3:19 AM, Clemens Ladisch wrote:
> Igor Korot wrote:
>> 1>odbccp32.lib(dllload.obj) : error LNK2019: unresolved external
>> symbol __imp___vsnprintf referenced in function
>> _StringVPrintfWorkerA at 20
>
> Looks like a bug in the MSVC libraries:
>
Igor Korot wrote:
> 1>odbccp32.lib(dllload.obj) : error LNK2019: unresolved external
> symbol __imp___vsnprintf referenced in function
> _StringVPrintfWorkerA at 20
Looks like a bug in the MSVC libraries:
Hello Igor,
I'm probably go the opposite direction and make sure everything is
built /MDd or /MD. Basically dynamic link the whole thing. It means
all of your projects need to be rebuilt using the same RTL though.
You just don't want 1/2 to be /MT and the other 1/2 to be /MD.
C
Hi, ALL,
On Tue, Jan 26, 2016 at 3:08 PM, Clemens Ladisch wrote:
> Igor Korot wrote:
>> sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p) Line 19996 + 0xc
>> bytesC
>> sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie) Line 726 + 0xc
>> bytesC
>>
Igor Korot wrote:
> sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p) Line 19996 + 0xc
> bytesC
> sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie) Line 726 + 0xc
> bytesC
> sqlite.dll!sqlite3_close(sqlite3 * db) Line 772 + 0xe bytesC
>
Igor Korot wrote:
> sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p) Line 19996 + 0xc
> bytesC
> sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie) Line 726 + 0xc
> bytesC
> sqlite.dll!sqlite3_close(sqlite3 * db) Line 772 + 0xe bytesC
>
Hello Igor,
https://msdn.microsoft.com/en-us/library/ms235460.aspx?f=255=-2147217396
This discussed in more details what I originally posted about.
>>A related problem can occur when you allocate memory (either
>>explicitly with new or malloc, or implicitly with strdup,
>>strstreambuf::str, and
Hi, Clemens,
On Tue, Jan 26, 2016 at 7:14 AM, Clemens Ladisch wrote:
> Igor Korot wrote:
>> sqlite.dll!sqlite3_mutex_enter(sqlite3_mutex * p) Line 19996 + 0xc
>> bytesC
>> sqlite.dll!sqlite3Close(sqlite3 * db, int forceZombie) Line 726 + 0xc
>> bytesC
>>
On Mon, Jan 25, 2016 at 2:44 PM, Teg wrote:
> >>Are you sure you're not somehow double-freeing the sqlite handle?
> >>Especially at close I've seen exit() end up calling atexit() methods
> >>multiple times in some circumstances...
>
> "newed" objects never fires the destructor unless you
Teg,
On Mon, Jan 25, 2016 at 9:25 PM, Igor Korot wrote:
> Hi, Teg,
>
> On Mon, Jan 25, 2016 at 5:21 PM, Igor Korot wrote:
>> Hi, Teg,
>>
>> On Mon, Jan 25, 2016 at 4:51 PM, Teg wrote:
>>> Hello Igor,
>>>
>>> Then I'd note the address of the object (make a copy of the pointer
>>> right as
Hi, Teg,
On Mon, Jan 25, 2016 at 5:21 PM, Igor Korot wrote:
> Hi, Teg,
>
> On Mon, Jan 25, 2016 at 4:51 PM, Teg wrote:
>> Hello Igor,
>>
>> Then I'd note the address of the object (make a copy of the pointer
>> right as it's allocated) and then verify that the address you're
>>
Igor Korot wrote:
> The DLL where SQLite pointer is alocated there is a DLLMain.
And what does it do?
> BOOL APIENTRY DLLMain()
> {
> }
Is it really empty?
> MainFrame::~MainFrame()
> {
> delete m_db; // this is where the crash happens
> }
When exactly is this destructor called?
Can you
Hi, Teg,
On Mon, Jan 25, 2016 at 4:51 PM, Teg wrote:
> Hello Igor,
>
> Then I'd note the address of the object (make a copy of the pointer
> right as it's allocated) and then verify that the address you're
> deleting is the same as the address that was allocated. I've verify
> that
Hello Igor,
Then I'd note the address of the object (make a copy of the pointer
right as it's allocated) and then verify that the address you're
deleting is the same as the address that was allocated. I've verify
that the correct calling convention is being used throughout too.
I'd
Hello J,
I don't typically use "new" in my C++ applications other than in
startup to allocate things that last the life of the application. So, I
don't have any issues with double-freeing. I never manually "new"
objects after startup. Instead I use containers to contains my objects
and leave the
Hi, Adam,
On Mon, Jan 25, 2016 at 2:46 PM, Adam Devita wrote:
> Hi Igor,
> I don't think you understood what I was trying to get at. Please
> allow me to rephrase: There isn't enough information about how things
> are being cleaned up to point out a problem, only make general
> suggestions
Hi Igor,
I don't think you understood what I was trying to get at. Please
allow me to rephrase: There isn't enough information about how things
are being cleaned up to point out a problem, only make general
suggestions about good practice.
This is why I was asking about where you would ensure
Hi, Adam,
On Mon, Jan 25, 2016 at 11:27 AM, Adam Devita wrote:
> Where do you pass to the dll something that goes to sqlite3_close(db); ?
> ( https://www.sqlite.org/c3ref/close.html )
> When that happens, does m_db get set to NULL (or now refers to memory
> that is now NULL)
> Do you check for
Hi, Peter,
On Mon, Jan 25, 2016 at 11:37 AM, Peter Aronson wrote:
> How are you building the DLL and the executable? Are they both including a
> copy of sqlite3.obj? Or are you using a sqlite3.dll?
I'm building SQLite from source.
The DLL and executable both do not reference
Hi, Teg,
On Mon, Jan 25, 2016 at 11:31 AM, Teg wrote:
> Hello Igor,
>
> MainFrame::~MainFrame()
> {
> delete m_db; // this is where the crash happens
> }
>
> I suspect you need to add a "Close" or destroy function to the DLL and
> pass the handle back to the DLL to let it get deleted in the
Hello Igor,
MainFrame::~MainFrame()
{
delete m_db; // this is where the crash happens
}
I suspect you need to add a "Close" or destroy function to the DLL and
pass the handle back to the DLL to let it get deleted in the DLL
context and not in the context of the caller.
extern "C"
Where do you pass to the dll something that goes to sqlite3_close(db); ?
( https://www.sqlite.org/c3ref/close.html )
When that happens, does m_db get set to NULL (or now refers to memory
that is now NULL)
Do you check for m_db == NULL before deleting it?
regards,
Adam DeVita
On Mon, Jan 25, 2016
Hi, Peter,
On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson wrote:
> Igor,
>
> You can't safely pass a SQLite handle between different SQL DLLs that way if
> they're both built with their own copy of the amalgamation (or link to
> things built with different copies). SQLite uses a handful of
Hi, Clemens,
On Mon, Jan 25, 2016 at 2:42 AM, Clemens Ladisch wrote:
> Igor Korot wrote:
>> Upon exiting from the application
>
> When exactly? Is DllMain() involved in any way?
The DLL where SQLite pointer is alocated there is a DLLMain.
Then this pointer is brought back to the main
On Mon, Jan 25, 2016 at 8:31 AM, Teg wrote:
> Hello Igor,
>
> extern "C" __declspec(dllexport) void DestroyObject(Database *db)
> {
> delete db;
> }
>
> It was my impression that each DLL got it's own heap so, memory
> allocated inside the DLL needs to be free'd inside the DLL. I use
>
How are you building the DLL and the executable? Are they both
including a copy of sqlite3.obj? Or are you using a sqlite3.dll?
Peter
On 1/25/2016 9:16 AM, Igor Korot wrote:
> Hi, Peter,
>
> On Mon, Jan 25, 2016 at 10:50 AM, Peter Aronson wrote:
>> Igor,
>>
>> You can't safely pass a SQLite
Igor,
You can't safely pass a SQLite handle between different SQL DLLs that
way if they're both built with their own copy of the amalgamation (or
link to things built with different copies). SQLite uses a handful of
global variables, but each DLL has its own copy of each of these global
Igor Korot wrote:
> Upon exiting from the application
When exactly? Is DllMain() involved in any way?
Regards,
Clemens
If it matters, I'm trying Win 8.1 with MSVC 2010.
Thank you.
On Mon, Jan 25, 2016 at 12:18 AM, Igor Korot wrote:
> Hi, ALL,
> I have a strange problem.
>
> I am trying to use sqlite in my program. It has a main application and
> couplef DLLs.
>
> I am getting the connection in one of the DLL,
Hi, ALL,
I have a strange problem.
I am trying to use sqlite in my program. It has a main application and
couplef DLLs.
I am getting the connection in one of the DLL, then the pointer is passed up
to the main application.
Upon exiting from the application I'm trying to close the connection and
Version 3.6.13 fixed some potential alignment issues that could occur on
SPARC (and potentially other) architectures. I don't know how you or Apple
are testing your app, but if you (or they) are using a device emulator for
the testing, the emulator might not be testing alignment conditions the
On Apr 21, 2009, at 11:10 AM, Mark Spiegel wrote:
> I'm a bit confused by the following:
>
> "The assign 100K or so to each database connection's lookaside memory
> allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...)
> immediately after it is opened."
>
> If memory is at a premium,
I'm a bit confused by the following:
"The assign 100K or so to each database connection's lookaside memory
allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...)
immediately after it is opened."
If memory is at a premium, why would you reserve a large amount of it
for SQLite's
>>> I have written an application for the iPhone called Grocery iQ that
>>> uses SQLite. I don't link to or use the built-in SQLite library on
>>> the iPhone. Instead, I compile the SQLite amalgamation into the
>>> executable. The SQLite version currently being used in our app is
>>> 3.6.7.
>>
On Apr 20, 2009, at 6:09 PM, D. Richard Hipp wrote:
>
> On Apr 20, 2009, at 5:32 PM, Jason Boehle wrote:
>
>> I have written an application for the iPhone called Grocery iQ that
>> uses SQLite. I don't link to or use the built-in SQLite library on
>> the iPhone. Instead, I compile the SQLite
On Apr 20, 2009, at 5:32 PM, Jason Boehle wrote:
> I have written an application for the iPhone called Grocery iQ that
> uses SQLite. I don't link to or use the built-in SQLite library on
> the iPhone. Instead, I compile the SQLite amalgamation into the
> executable. The SQLite version
I have written an application for the iPhone called Grocery iQ that
uses SQLite. I don't link to or use the built-in SQLite library on
the iPhone. Instead, I compile the SQLite amalgamation into the
executable. The SQLite version currently being used in our app is
3.6.7.
We have been working
40 matches
Mail list logo
