* [lttng-dev] question about rcu_bp_exit() [not found] <6db07fb4.c6e5.154c340296f.Coremail.songxin_1980@126.com> @ 2016-05-18 18:40 ` Mathieu Desnoyers 2016-05-19 19:53 ` Paul E. McKenney 0 siblings, 1 reply; 2+ messages in thread From: Mathieu Desnoyers @ 2016-05-18 18:40 UTC (permalink / raw) ----- On May 18, 2016, at 5:44 AM, songxin <songxin_1980 at 126.com> wrote: > Hi, > Now I get a crash because receiving signal SIGSEGV as below. > #0 arena_alloc (arena=<optimized out>) at > /usr/src/debug/liburcu/0.9.1+git5fd33b1e5003ca316bd314ec3fd1447f6199a282-r0/git/urcu-bp.c:432 > #1 add_thread () at > /usr/src/debug/liburcu/0.9.1+git5fd33b1e5003ca316bd314ec3fd1447f6199a282-r0/git/urcu-bp.c:462 > #2 rcu_bp_register () at > /usr/src/debug/liburcu/0.9.1+git5fd33b1e5003ca316bd314ec3fd1447f6199a282-r0/git/urcu-bp.c:541 > I read the code of urcu-bp.c and found that "if (chunk->data_len - chunk->used < > len)" is in 432 line. So I guess that the chunk is a illegal pointer. > Below is the function rcu_bp_exit(). > static > void rcu_bp_exit(void) > { > mutex_lock(&init_lock); > if (!--rcu_bp_refcount) { > struct registry_chunk *chunk, *tmp; > int ret; > cds_list_for_each_entry_safe(chunk, tmp, > ®istry_arena.chunk_list, node) { > munmap(chunk, chunk->data_len > + sizeof(struct registry_chunk)); > } > ret = pthread_key_delete(urcu_bp_key); > if (ret) > abort(); > } > mutex_unlock(&init_lock); > } > My question is below. > Why did not delete the chunk from registry_arena.chunk_list before munmap a > chunk? It is not expected that any thread would be created after the execution of rcu_bp_exit() as a library destructor. Does re-initializing the chunk_list after iterating on it within rcu_bp_exit() fix your issue ? I'm curious about your use-case for creating threads after the library destructor has run. Thanks, Mathieu > Thanks, > xin > _______________________________________________ > lttng-dev mailing list > lttng-dev at lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160518/5c64b2ef/attachment.html> ^ permalink raw reply [flat|nested] 2+ messages in thread
* [lttng-dev] question about rcu_bp_exit() 2016-05-18 18:40 ` [lttng-dev] question about rcu_bp_exit() Mathieu Desnoyers @ 2016-05-19 19:53 ` Paul E. McKenney 0 siblings, 0 replies; 2+ messages in thread From: Paul E. McKenney @ 2016-05-19 19:53 UTC (permalink / raw) On Wed, May 18, 2016 at 06:40:03PM +0000, Mathieu Desnoyers wrote: > ----- On May 18, 2016, at 5:44 AM, songxin <songxin_1980 at 126.com> wrote: > > > Hi, > > Now I get a crash because receiving signal SIGSEGV as below. > > > #0 arena_alloc (arena=<optimized out>) at > > /usr/src/debug/liburcu/0.9.1+git5fd33b1e5003ca316bd314ec3fd1447f6199a282-r0/git/urcu-bp.c:432 > > #1 add_thread () at > > /usr/src/debug/liburcu/0.9.1+git5fd33b1e5003ca316bd314ec3fd1447f6199a282-r0/git/urcu-bp.c:462 > > #2 rcu_bp_register () at > > /usr/src/debug/liburcu/0.9.1+git5fd33b1e5003ca316bd314ec3fd1447f6199a282-r0/git/urcu-bp.c:541 > > > I read the code of urcu-bp.c and found that "if (chunk->data_len - chunk->used < > > len)" is in 432 line. So I guess that the chunk is a illegal pointer. > > Below is the function rcu_bp_exit(). > > > static > > void rcu_bp_exit(void) > > { > > mutex_lock(&init_lock); > > if (!--rcu_bp_refcount) { > > struct registry_chunk *chunk, *tmp; > > int ret; > > > cds_list_for_each_entry_safe(chunk, tmp, > > ®istry_arena.chunk_list, node) { > > munmap(chunk, chunk->data_len > > + sizeof(struct registry_chunk)); > > } > > ret = pthread_key_delete(urcu_bp_key); > > if (ret) > > abort(); > > } > > mutex_unlock(&init_lock); > > } > > > My question is below. > > Why did not delete the chunk from registry_arena.chunk_list before munmap a > > chunk? > > It is not expected that any thread would be created after the execution of > rcu_bp_exit() as a library destructor. Does re-initializing the chunk_list after > iterating on it within rcu_bp_exit() fix your issue ? > > I'm curious about your use-case for creating threads after the library destructor > has run. I am with Mathieu on this -- not much good can be expected using things after their cleanup. Though I suppose that, given a sufficient use case, there could at least in theory be an option for manual control of cleanup. Thanx, Paul ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-05-19 19:53 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <6db07fb4.c6e5.154c340296f.Coremail.songxin_1980@126.com>
2016-05-18 18:40 ` [lttng-dev] question about rcu_bp_exit() Mathieu Desnoyers
2016-05-19 19:53 ` Paul E. McKenney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox