From: Andy Wingo <wingo@pobox.com>
To: guile-devel <guile-devel@gnu.org>
Subject: allocation within critical sections
Date: Thu, 09 Feb 2012 20:15:38 +0100 [thread overview]
Message-ID: <87sjijzulh.fsf@pobox.com> (raw)
Hi,
FYI: Allocating memory can run finalizers, which can run arbitrary code.
So if you allocate memory from within a critical section, i.e. while a
mutex is held, you need to be really sure that there's no way a
finalizer would try to grab the lock you are already holding.
In some cases it's best to simply avoid allocation while holding a lock.
Andy, who got the following backtrace, with wip-threads-and-fork:
#0 0x00007f5daf443cec in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f5daf43f339 in _L_lock_926 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f5daf43f15b in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#3 0x00007f5dafba8563 in finalize_port (ptr=0x3dac5a0, data=<optimized out>) at ports.c:575
#4 finalize_port (ptr=0x3dac5a0, data=<optimized out>) at ports.c:551
#5 0x00007f5daee5851e in GC_invoke_finalizers () at finalize.c:872
#6 0x00007f5daee5876e in GC_notify_or_invoke_finalizers () at finalize.c:951
#7 0x00007f5daee5ab4d in GC_generic_malloc_many (lb=16, k=1, result=0x7f5daf080d30) at mallocx.c:290
#8 0x00007f5daee640a1 in GC_malloc (bytes=16) at thread_local_alloc.c:177
#9 0x00007f5dafba690e in scm_cell (cdr=772, car=2052) at ../libguile/gc.h:204
#10 scm_cons (x=<optimized out>, y=0x304) at pairs.c:77
#11 0x00007f5dafb8cc6e in scm_make_list (n=<optimized out>, init=0x804) at list.c:120
#12 0x00007f5dafb82c39 in finalize_guarded (ptr=<optimized out>, finalizer_data=<optimized out>) at guardians.c:124
#13 0x00007f5daee5851e in GC_invoke_finalizers () at finalize.c:872
#14 0x00007f5daee5876e in GC_notify_or_invoke_finalizers () at finalize.c:951
#15 0x00007f5daee5ab4d in GC_generic_malloc_many (lb=16, k=1, result=0x7f5daf080d30) at mallocx.c:290
#16 0x00007f5daee640a1 in GC_malloc (bytes=16) at thread_local_alloc.c:177
#17 0x00007f5dafba690e in scm_cell (cdr=65961984, car=36468752) at ../libguile/gc.h:204
#18 scm_cons (x=<optimized out>, y=0x3ee8000) at pairs.c:77
#19 0x00007f5dafbf5b6f in lock_all_weak_tables (unused=<optimized out>) at weak-table.c:762
#20 0x00007f5dafbf8c97 in before_fork () at posix.c:1295
#21 scm_fork () at posix.c:1328
--
http://wingolog.org/
next reply other threads:[~2012-02-09 19:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 19:15 Andy Wingo [this message]
2012-02-13 10:38 ` allocation within critical sections Andy Wingo
2012-02-13 15:29 ` Andy Wingo
2012-02-16 21:30 ` Ludovic Courtès
2012-02-16 22:27 ` Andy Wingo
2012-02-17 2:46 ` Mike Gran
2012-02-17 8:16 ` Andy Wingo
2012-02-17 10:32 ` Mike Gran
2012-02-17 15:20 ` Andy Wingo
2012-02-17 22:59 ` Ludovic Courtès
2012-02-19 9:42 ` Andy Wingo
2012-02-19 20:56 ` Ludovic Courtès
2012-02-19 21:29 ` Andy Wingo
2012-02-24 15:04 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sjijzulh.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).