Dont shoot the messenger plz :-)
running some tests using sqlite I'm getting what appears to be stack corruption:
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb78cbf75 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb78cd8f1 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d01b95 in Util_abort (e=0xb7d102a0 "MemoryException -- %s at %s in line %d\n") at src/util/Util.c:83 #4 0xb7d023d2 in Mem_resize (p=0x5316e008, size=1665138688, file=0xb7d214c0 "src/util/StringBuffer.c", line=61) at src/util/Mem.c:76 #5 0xb7d07c29 in StringBuffer_vappend (S=0x8115438, s=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/util/StringBuffer.c:61 #6 0xb7d0e88f in SQLiteConnection_execute (C=0x8115de8, sql=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/db/sqlite/SQLiteConnection.c:174
any ideas?
Could you try and create a test program that reproduce this and the MySQL error you previously reported. I have not seen these problems before myself. I don't know if you do, but notice that sharing a Connection, PreparedStatement or ResultSet between threads is not thread-safe and will open a can of worms.
On 5. april. 2008, at 16.59, Paul J Stevens wrote:
Dont shoot the messenger plz :-)
running some tests using sqlite I'm getting what appears to be stack corruption:
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb78cbf75 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb78cd8f1 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d01b95 in Util_abort (e=0xb7d102a0 "MemoryException -- %s at %s in line %d\n") at src/util/Util.c:83 #4 0xb7d023d2 in Mem_resize (p=0x5316e008, size=1665138688, file=0xb7d214c0 "src/util/StringBuffer.c", line=61) at src/util/ Mem.c:76 #5 0xb7d07c29 in StringBuffer_vappend (S=0x8115438, s=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/util/StringBuffer.c:61 #6 0xb7d0e88f in SQLiteConnection_execute (C=0x8115de8, sql=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/db/sqlite/ SQLiteConnection.c:174
any ideas?
Jan-Henrik Haukeland wrote:
Could you try and create a test program that reproduce this and the MySQL error you previously reported. I have not seen these problems before myself. I don't know if you do, but notice that sharing a Connection, PreparedStatement or ResultSet between threads is not thread-safe and will open a can of worms.
That I dont do, afaik. I always fetch a connection, execute, handle result, and return the connection within a single thread. I will double check, but I've hardly begun using threads so there's not many places to look. Also, the postgres driver is much more stable at the moment. I'm still seeing some crashes there as well, but those are few and very far between, but also point to Connection_clear.
On 5. april. 2008, at 16.59, Paul J Stevens wrote:
Dont shoot the messenger plz :-)
running some tests using sqlite I'm getting what appears to be stack corruption:
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb78cbf75 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb78cd8f1 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d01b95 in Util_abort (e=0xb7d102a0 "MemoryException -- %s at %s in line %d\n") at src/util/Util.c:83 #4 0xb7d023d2 in Mem_resize (p=0x5316e008, size=1665138688, file=0xb7d214c0 "src/util/StringBuffer.c", line=61) at src/util/ Mem.c:76 #5 0xb7d07c29 in StringBuffer_vappend (S=0x8115438, s=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/util/StringBuffer.c:61 #6 0xb7d0e88f in SQLiteConnection_execute (C=0x8115de8, sql=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/db/sqlite/ SQLiteConnection.c:174
any ideas?
-- To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
I have a feeling or rather hope that it all boils down to a trivial error in StringBuffer. Could you try again with the latest from svn?
On 5. april. 2008, at 20.27, Paul J Stevens wrote:
Jan-Henrik Haukeland wrote:
Could you try and create a test program that reproduce this and the MySQL error you previously reported. I have not seen these problems before myself. I don't know if you do, but notice that sharing a Connection, PreparedStatement or ResultSet between threads is not thread-safe and will open a can of worms.
That I dont do, afaik. I always fetch a connection, execute, handle result, and return the connection within a single thread. I will double check, but I've hardly begun using threads so there's not many places to look. Also, the postgres driver is much more stable at the moment. I'm still seeing some crashes there as well, but those are few and very far between, but also point to Connection_clear.
On 5. april. 2008, at 16.59, Paul J Stevens wrote:
Dont shoot the messenger plz :-)
running some tests using sqlite I'm getting what appears to be stack corruption:
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb78cbf75 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb78cd8f1 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d01b95 in Util_abort (e=0xb7d102a0 "MemoryException -- %s at %s in line %d\n") at src/util/Util.c:83 #4 0xb7d023d2 in Mem_resize (p=0x5316e008, size=1665138688, file=0xb7d214c0 "src/util/StringBuffer.c", line=61) at src/util/ Mem.c:76 #5 0xb7d07c29 in StringBuffer_vappend (S=0x8115438, s=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/util/StringBuffer.c:61 #6 0xb7d0e88f in SQLiteConnection_execute (C=0x8115de8, sql=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/db/sqlite/ SQLiteConnection.c:174
any ideas?
-- To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
-- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl -- To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
Alas,
I think the va_copy trick is spot on, but it should also be applied in SQLiteConnection_execute and friends, if I read stdarg(3) correctly.
Jan-Henrik Haukeland wrote:
I have a feeling or rather hope that it all boils down to a trivial error in StringBuffer. Could you try again with the latest from svn?
On 5. april. 2008, at 20.27, Paul J Stevens wrote:
Jan-Henrik Haukeland wrote:
Could you try and create a test program that reproduce this and the MySQL error you previously reported. I have not seen these problems before myself. I don't know if you do, but notice that sharing a Connection, PreparedStatement or ResultSet between threads is not thread-safe and will open a can of worms.
That I dont do, afaik. I always fetch a connection, execute, handle result, and return the connection within a single thread. I will double check, but I've hardly begun using threads so there's not many places to look. Also, the postgres driver is much more stable at the moment. I'm still seeing some crashes there as well, but those are few and very far between, but also point to Connection_clear.
On 5. april. 2008, at 16.59, Paul J Stevens wrote:
Dont shoot the messenger plz :-)
running some tests using sqlite I'm getting what appears to be stack corruption:
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb78cbf75 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb78cd8f1 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d01b95 in Util_abort (e=0xb7d102a0 "MemoryException -- %s at %s in line %d\n") at src/util/Util.c:83 #4 0xb7d023d2 in Mem_resize (p=0x5316e008, size=1665138688, file=0xb7d214c0 "src/util/StringBuffer.c", line=61) at src/util/ Mem.c:76 #5 0xb7d07c29 in StringBuffer_vappend (S=0x8115438, s=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/util/StringBuffer.c:61 #6 0xb7d0e88f in SQLiteConnection_execute (C=0x8115de8, sql=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/db/sqlite/ SQLiteConnection.c:174
any ideas?
-- To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
-- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl -- To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
-- To unsubscribe: http://www.tildeslash.com/mailman/listinfo/libzdb-general
On 5. april. 2008, at 23.00, Paul J Stevens wrote:
Alas,
I think the va_copy trick is spot on, but it should also be applied in SQLiteConnection_execute and friends, if I read stdarg(3) correctly.
Lets hope so, and certainly, va_copy is now used all over the place where applicable. I'll hold on with a new bug release for a while, to see if you will dig up more stuff :) As a side note, it is system dependent if it is necessary to do a va_copy when passing a va_list down the call stack. On OSX is probably not necessary since I've not had any problems. Though using va_copy should of course be done anyway.
Actually, this one may be as simple as using va_list ap_copy in StringBuffer to ensure that the argument list is valid and guard against an off-by-one bug. I have checked in a new version to the repository and if you could test, that would be swell. Otherwise if you get this again, could you look closer at the StringBuffer memory buffer to see if it looks valid.
On 5. april. 2008, at 16.59, Paul J Stevens wrote:
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb78cbf75 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb78cd8f1 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d01b95 in Util_abort (e=0xb7d102a0 "MemoryException -- %s at %s in line %d\n") at src/util/Util.c:83 #4 0xb7d023d2 in Mem_resize (p=0x5316e008, size=1665138688, file=0xb7d214c0 "src/util/StringBuffer.c", line=61) at src/util/ Mem.c:76 #5 0xb7d07c29 in StringBuffer_vappend (S=0x8115438, s=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/util/StringBuffer.c:61 #6 0xb7d0e88f in SQLiteConnection_execute (C=0x8115de8, sql=0x81008c0 "UPDATE OR IGNORE dbmail_mailboxes SET mtime=STRFTIME('%Y-%m-%d %H:%M:%S','now','localtime') WHERE mailbox_idnr=2", ap=0xbfe38778 "{z\t\b��\t\b�") at src/db/sqlite/ SQLiteConnection.c:174
Paul J Stevens wrote:
running some tests using sqlite I'm getting what appears to be stack corruption:
forget about this one.
A combination of the lastRowId issue and incorrect sprintf template construction.
-
Jan-Henrik Haukeland -
Paul J Stevens