segfault in load-extension but not in app

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

segfault in load-extension but not in app

sub sk79
Hi,

I am getting seg fault when same code is run as loadable-extension but not
when run as shared lib linked to app.
Thanks in advance for all help.

The C++ code is compiled to
1. shared library and linked to app
2. loadable-extension and loaded from sqlite command line using '.load'.

The C++ code is exactly same in both cases (except extension init section)

Sqlite version is 3.21.0. Ubuntu 16.04 LTS 64-bit in virtualbox VM on
windows 7 host. GCC 6.1.0

I do not get any issues when the code is run as app.
The code runs fine as loadable-extension as well except, it SEG faults
during cleanup:
Here are two snippets of the app's C++ code where I have observed this:
==========Snippet 1====
          //Drop all views created in sqlite
          std::vector <std::string> view_vector;
          view_vector.push_back("MYDATA");

        std::string dropView;
          for (std::vector <std::string>::iterator
iter=view_vector.begin(); iter != view_vector.end(); ++iter)
          {
                LOG_DEBUG << "Dropping View: " << (*iter) << endl;
            dropView=("DROP VIEW IF EXISTS "+(*iter));
                if (SQLITE_OK != sqlite3_exec(m_pDb, dropView.c_str(),
NULL, NULL, NULL))
                {
                     LOG_ERROR << "Exec failed for Drop View " << (*iter)
<< ". Error Code= " << sqlite3_errcode(m_pDb)<< " Error Message= "<<
sqlite3_errmsg(m_pDb) << " Line=" << __LINE__ << endl;
                };
          };
==========Snippet 2====
          //Generic Finalize loop -- requires Sqlite version 3.5+
        //NOTE: Since we are finalizing it is correct to pass 0 as second
arg all the time.
          sqlite3_stmt *pStmt;
          while( (pStmt = sqlite3_next_stmt(m_pDb, 0))!=0 )
          {
            LOG_TRACE << "Finalizing SQL: " << sqlite3_sql(pStmt) <<endl;
                sqlite3_finalize(pStmt);
          }

==========
==========
(gdb) where
#0  malloc_consolidate (av=av@entry=0x7ffff79b0b20 <main_arena>) at
malloc.c:4167
#1  0x00007ffff766dcde in _int_malloc (av=av@entry=0x7ffff79b0b20
<main_arena>, bytes=bytes@entry=1032) at malloc.c:3450
#2  0x00007ffff7670184 in __GI___libc_malloc (bytes=1032) at malloc.c:2913
#3  0x000000000042cce3 in sqlite3MemMalloc ()
#4  0x000000000041b33a in sqlite3Malloc ()
#5  0x000000000041b6a7 in dbMallocRawFinish ()
#6  0x0000000000427a13 in growOpArray.isra.378 ()
#7  0x0000000000427a5f in growOp3 ()
#8  0x0000000000427b54 in sqlite3VdbeCreate ()
#9  0x000000000046bef7 in sqlite3DropTable ()
#10 0x00000000004678ae in sqlite3RunParser ()
#11 0x000000000046aef9 in sqlite3Prepare ()
#12 0x000000000046b207 in sqlite3LockAndPrepare ()
#13 0x000000000046b41d in sqlite3_prepare_v2 ()
#14 0x000000000045de9e in sqlite3_exec ()
#15 0x00007ffff69032ab in WRAPPER1::~WRAPPER1 (this=0x6d3c40,
__in_chrg=<optimized out>) at src/wrapper1_defn.cpp:209
#16 0x00007ffff6901171 in WRAPPER1::removeInstance () at
src/wrapper1_defn.cpp:81
#17 0x00007ffff6900207 in ss_world::removeInstance (this=0x7ffff6dab1a0
<l_ss_world>) at src/load_extension.cpp:186
#18 0x00007ffff68fe2d0 in ss_world::~ss_world (this=0x7ffff6dab1a0
<l_ss_world>, __in_chrg=<optimized out>) at src/load_extension.cpp:28
#19 0x00007ffff7625ff8 in __run_exit_handlers (status=0,
listp=0x7ffff79b05f8 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true)
at exit.c:82
#20 0x00007ffff7626045 in __GI_exit (status=<optimized out>) at exit.c:104
#21 0x00007ffff760c837 in __libc_start_main (main=0x404550 <main>, argc=4,
argv=0x7fffffffdb58, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffdb48) at
../csu/libc-start.c:325
#22 0x00000000004052b9 in _start ()
(gdb)

==========

Sometimes I also get SEG fault at:
===============
(gdb) where
#0  malloc_consolidate (av=av@entry=0x7ffff79b0b20 <main_arena>) at
malloc.c:4167
#1  0x00007ffff766c678 in _int_free (av=0x7ffff79b0b20 <main_arena>,
p=<optimized out>, have_lock=0) at malloc.c:4075
#2  0x00007ffff767053c in __GI___libc_free (mem=<optimized out>) at
malloc.c:2968
#3  0x0000000000417074 in sqlite3_free ()
#4  0x0000000000421572 in sqlite3VdbeClearObject ()
#5  0x0000000000421954 in sqlite3VdbeDelete ()
#6  0x0000000000454b74 in sqlite3VdbeFinalize ()
#7  0x0000000000454bde in sqlite3_finalize ()
#8  0x00007ffff6889a2a in WRAPPER1::~WRAPPER1 (this=0x7121e0,
__in_chrg=<optimized out>) at src/wrapper1_defn.cpp:181
#9  0x00007ffff6887de5 in WRAPPER1::removeInstance () at
src/wrapper1_defn.cpp:81
#10 0x00007ffff6886e71 in ss_world::removeInstance (this=0x7ffff6daa8e0
<l_ss_world>) at src/load_extension.cpp:196
#11 0x00007ffff6884e80 in ss_world::~ss_world (this=0x7ffff6daa8e0
<l_ss_world>, __in_chrg=<optimized out>) at src/load_extension.cpp:30
#12 0x00007ffff7625ff8 in __run_exit_handlers (status=0,
listp=0x7ffff79b05f8 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true)
at exit.c:82
#13 0x00007ffff7626045 in __GI_exit (status=<optimized out>) at exit.c:104
#14 0x00007ffff760c837 in __libc_start_main (main=0x404550 <main>, argc=4,
argv=0x7fffffffdb58, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffdb48) at
../csu/libc-start.c:325
#15 0x00000000004052b9 in _start ()
(gdb)

===============

I suspect memory corruption so I ran valgrind. It reports some possible
lost blocks during extension loading but none during shared library linked
to app.

==============Valgrind report with loadable-extension(reports
errors)===========
==32189== HEAP SUMMARY:
==32189==     in use at exit: 378,139 bytes in 601 blocks
==32189==   total heap usage: 7,315 allocs, 6,714 frees, 2,759,824 bytes
allocated
==32189==
==32189== 4,104 bytes in 1 blocks are possibly lost in loss record 286 of
294
==32189==    at 0x4C2DB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32189==    by 0x42CCE2: sqlite3MemMalloc (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x41B339: sqlite3Malloc (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x41F3D1: pcache1Alloc (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x42D679: sqlite3BtreeCursor (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x4588E3: sqlite3VdbeExec (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x45D394: sqlite3_step (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x45DEF6: sqlite3_exec (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==    by 0x62E9F5D: WRAPPER2::prepareStatements(sqlite3*)
(wrapper2_defn.cpp:454)
==32189==    by 0x62CA1FC: ss_world::init(sqlite3*, LOG_LEVEL)
(load_extension.cpp:68)
==32189==    by 0x62CC04B: sqlite3_extension_init (load_extension.cpp:232)
==32189==    by 0x43BEA3: sqlite3_load_extension (in
/home/skashikar/utils/sqlite/sqlite-autoconf-3210000/installation/bin/sqlite3)
==32189==
==32189== LEAK SUMMARY:
==32189==    definitely lost: 0 bytes in 0 blocks
==32189==    indirectly lost: 0 bytes in 0 blocks
==32189==      possibly lost: 4,104 bytes in 1 blocks
==32189==    still reachable: 374,035 bytes in 600 blocks
==32189==                       of which reachable via heuristic:
==32189==                         length64           : 281,856 bytes in 574
blocks
==32189==         suppressed: 0 bytes in 0 blocks
==32189== Reachable blocks (those to which a pointer was found) are not
shown.
==32189== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==32189==
==32189== For counts of detected and suppressed errors, rerun with: -v
==32189== ERROR SUMMARY: 64 errors from 6 contexts (suppressed: 0 from 0)

================

==============Valgrind report with app (reports no errors)===========
==32390==
==32390== HEAP SUMMARY:
==32390==     in use at exit: 72,704 bytes in 1 blocks
==32390==   total heap usage: 8,223 allocs, 8,222 frees, 3,454,704 bytes
allocated
==32390==
==32390== LEAK SUMMARY:
==32390==    definitely lost: 0 bytes in 0 blocks
==32390==    indirectly lost: 0 bytes in 0 blocks
==32390==      possibly lost: 0 bytes in 0 blocks
==32390==    still reachable: 72,704 bytes in 1 blocks
==32390==         suppressed: 0 bytes in 0 blocks
==32390== Reachable blocks (those to which a pointer was found) are not
shown.
==32390== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==32390==
==32390== For counts of detected and suppressed errors, rerun with: -v
==32390== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==============
Thanks,
SK
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users