Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

filter().changes() order by "time" index breaks down the db #5081

Closed
lijialing888 opened this issue Nov 13, 2015 · 6 comments
Closed

filter().changes() order by "time" index breaks down the db #5081

lijialing888 opened this issue Nov 13, 2015 · 6 comments
Assignees
@mlucy
Labels
tp:bug
Milestone
2.2.1

Comments

@lijialing888
Copy link

Hi guys,
I run 2 processes: 1 to write records, 1 to listen the changes. When I make order by the "createTime" index will make the db break down.
But order by other index (like integer) is fine.

Write node script:

setInterval(function() {
    ...
    r.table('alarms').insert({
        id: ++count,
        content: content,
        createTime: r.now()
        ...
    }).run(conn, function (err, result) {
        ...
    })
}, 500);

Listener node script:

r.table('alarms').orderBy({index: r.desc('createTime')}).
filter({severity: 'Minor'}).limit(10).changes().
run(conn, function (err, cursor) {

});

Error Message:
rethinkdb 2.1.5+2~0precise (GCC 4.6.3)
error: Error in src/arch/runtime/thread_pool.cc at line 359:
error: Segmentation fault from reading the address 0x8.
error: Backtrace:

Enviroment:
uname -a
Linux ubuntu-ljl 3.13.0-68-generic #111~precise1-Ubuntu SMP Fri Nov 6 18:17:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

rethinkdb --version
rethinkdb 2.1.5+2~0precise (GCC 4.6.3)
@danielmewes
Copy link
Member

Thanks for reporting this @lijialing888, and sorry you had to run into this.
I was able to reproduce the issue and can confirm that it's still an issue in RethinkDB 2.2.0.
Interestingly, I can only get the crash with descending ordering on the index, not with ascending ordering.

To reproduce, I used the following queries:

r.tableCreate('t1')
r.table('t1').indexCreate('t')
r.table('t1').insert({t: r.now()})
r.table('t1').insert({t: r.now()})
r.table('t1').orderBy({index: r.desc("t")}).limit(1).changes()
// While the changefeed is active:
r.table('t1').insert({t: r.now()})
r.table('t1').insert({t: r.now()})

The exact number of documents you need to insert before / after starting the changefeed might vary a bit.

Backtrace from 2.2.0:

error: Thu Nov 12 19:38:53 2015

       1 [0xafd133]: format_backtrace(bool) at 0xafd133 (rethinkdb)
       2 [0xd9f134]: report_fatal_error(char const*, int, char const*, ...) at 0xd9f134 (rethinkdb)
       3 [0xa09a53]: linux_thread_pool_t::fatal_signal_handler(int, siginfo*, void*) at 0xa09a53 (rethinkdb)
       4 [0x7fe7c5acf340]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fe7c5acf340] at 0x7fe7c5acf340 (/lib/x86_64-linux-gnu/libpthread.so.0)
       5 [0xa72790]: shared_buf_t::size() const at 0xa72790 (rethinkdb)
       6 [0x99bb63]: ql::datum_get_array_size(shared_buf_ref_t<char> const&) at 0x99bb63 (rethinkdb)
       7 [0x93e5f0]: ql::datum_t::obj_size() const at 0x93e5f0 (rethinkdb)
       8 [0x93e9e2]: rethinkdb() [0x93e9e2] at 0x93e9e2 ()
       9 [0x93eba0]: ql::datum_t::is_ptype() const at 0x93eba0 (rethinkdb)
       10 [0x943a02]: ql::datum_t::cmp_unchecked_stack(ql::datum_t const&) const at 0x943a02 (rethinkdb)
       11 [0x94428e]: ql::datum_t::cmp(ql::datum_t const&) const at 0x94428e (rethinkdb)
       12 [0x8f7107]: ql::changefeed::limit_order_t::subop(std::string const&, std::pair<ql::datum_t, ql::datum_t> const&, std::string const&, std::pair<ql::datum_t, ql::datum_t> const&) const at 0x8f7107 (rethinkdb)
       13 [0x8f4300]: rethinkdb() [0x8f4300] at 0x8f4300 ()
       14 [0x90d9fc]: ql::changefeed::index_queue_t<std::string, ql::datum_t, ql::datum_t, ql::changefeed::limit_order_t>::erase(std::_Rb_tree_iterator<std::pair<std::string const, std::pair<ql::datum_t, ql::datum_t> > >) at 0x90d9fc (rethinkdb)
       15 [0x9015dd]: ql::changefeed::limit_manager_t::commit(rwlock_in_line_t*, boost::variant<ql::changefeed::primary_ref_t, ql::changefeed::sindex_ref_t, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_> const&) at 0x9015dd (rethinkdb)
       16 [0x8173b3]: rethinkdb() [0x8173b3] at 0x8173b3 ()
       17 [0x8ff9b8]: ql::changefeed::server_t::foreach_limit(boost::optional<std::string> const&, store_key_t const*, std::function<void (rwlock_in_line_t*, rwlock_in_line_t*, rwlock_in_line_t*, ql::changefeed::limit_manager_t*)>, auto_drainer_t::lock_t const&) at 0x8ff9b8 (rethinkdb)
       18 [0x81b823]: rdb_update_single_sindex(store_t*, store_t::sindex_access_t const*, deletion_context_t const*, rdb_modification_report_t const*, unsigned long*, auto_drainer_t::lock_t, cond_t*, std::vector<std::pair<ql::datum_t, boost::optional<unsigned long> >, std::allocator<std::pair<ql::datum_t, boost::optional<unsigned long> > > >*, std::vector<std::pair<ql::datum_t, boost::optional<unsigned long> >, std::allocator<std::pair<ql::datum_t, boost::optional<unsigned long> > > >*) at 0x81b823 (rethinkdb)
       19 [0x823f77]: callable_action_instance_t<std::_Bind<void (*(store_t*, store_t::sindex_access_t*, deletion_context_t const*, rdb_modification_report_t const*, unsigned long*, auto_drainer_t::lock_t, cond_t*, std::vector<std::pair<ql::datum_t, boost::optional<unsigned long> >, std::allocator<std::pair<ql::datum_t, boost::optional<unsigned long> > > >*, std::vector<std::pair<ql::datum_t, boost::optional<unsigned long> >, std::allocator<std::pair<ql::datum_t, boost::optional<unsigned long> > > >*))(store_t*, store_t::sindex_access_t const*, deletion_context_t const*, rdb_modification_report_t const*, unsigned long*, auto_drainer_t::lock_t, cond_t*, std::vector<std::pair<ql::datum_t, boost::optional<unsigned long> >, std::allocator<std::pair<ql::datum_t, boost::optional<unsigned long> > > >*, std::vector<std::pair<ql::datum_t, boost::optional<unsigned long> >, std::allocator<std::pair<ql::datum_t, boost::optional<unsigned long> > > >*)> >::run_action() at 0x823f77 (rethinkdb)
       20 [0xa0b28e]: coro_t::run() at 0xa0b28e (rethinkdb)

@danielmewes
Copy link
Member

Assigning @mlucy

@danielmewes danielmewes added this to the 2.2-polish milestone Nov 13, 2015
@danielmewes danielmewes modified the milestones: 2.2-polish, 2.2.x Nov 13, 2015
@mlucy
Copy link
Member

mlucy commented Nov 14, 2015

Thanks for the bug report! I think we tracked this down, a fix is in CR 3336 by @danielmewes .

@danielmewes danielmewes modified the milestones: 2.2.1, 2.2.x Nov 16, 2015
@mlucy
Copy link
Member

mlucy commented Nov 16, 2015

This fix is in next and 2.2.x.

@mlucy mlucy closed this as completed Nov 16, 2015
@lijialing888
Copy link
Author

Hi @mlucy and @danielmewes ,
today I find changes feed descending order by "string" field and concurrently insert new records , It crashes down too.
Is it the same problem?

Version: rethinkdb 2.1.5+2~0precise (GCC 4.6.3)
error: Error in src/arch/runtime/thread_pool.cc at line 359:
error: Segmentation fault from reading the address 0x8.
error: Backtrace:

@danielmewes
Copy link
Member

@lijialing888 Pretty sure that's the same problem. We've just released RethinkDB 2.2.1 with a fix for this. Could you upgrade to that version and try again? You might want to read the 2.2.0 release notes for details on backwards compatiblity and migration: https://github.com/rethinkdb/rethinkdb/releases/tag/v2.2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mlucy mlucy

Labels
tp:bug
Projects
None yet
Milestone
2.2.1
Development

No branches or pull requests
3 participants
@danielmewes @mlucy @lijialing888