caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rich@annexia.org>
To: caml-list@inria.fr
Subject: [Caml-list] Anyone else seeing core dumps in caml_thread_reinitialize?
Date: Mon, 16 Jul 2012 13:23:27 +0100	[thread overview]
Message-ID: <20120716122327.GA16367@annexia.org> (raw)


I'm certainly not ruling out a bug in either libguestfs or our OCaml
4.00.0 +beta2 package, but has anyone who writes highly intensive
multithreaded programs which also fork seen segfaults in
caml_thread_reinitialize just after the fork?

The actual code being hit is:

  static void caml_thread_reinitialize(void)
  {
    caml_thread_t thr, next;
    struct channel * chan;

    /* Remove all other threads (now nonexistent)
       from the doubly-linked list of threads */
    thr = curr_thread->next;
    while (thr != curr_thread) {
      next = thr->next;            <---
      stat_free(thr);
      thr = next;
    }

and here is the stack trace:

#0  0x00000000004abcc8 in caml_thread_reinitialize ()
#1  0x0000003fc26bab9e in __libc_fork ()
    at ../nptl/sysdeps/unix/sysv/linux/fork.c:188
#2  0x0000003fc266cf34 in _IO_new_proc_open (fp=fp@entry=0x7f7868000f30, 
    command=command@entry=0x7f787a7fa2c0 "LC_ALL=C '/bin/qemu-kvm' -nographic -version 2>/dev/null", mode=<optimized out>, mode@entry=0x7f7881ecd090 "r")
    at iopopen.c:187
#3  0x0000003fc266d1c7 in _IO_new_popen (
    command=0x7f787a7fa2c0 "LC_ALL=C '/bin/qemu-kvm' -nographic -version 2>/dev/null", mode=0x7f7881ecd090 "r") at iopopen.c:308
#4  0x00007f7881eab88d in test_qemu_cmd (g=g@entry=0x7f78680008c0, 
    cmd=cmd@entry=0x7f787a7fa2c0 "LC_ALL=C '/bin/qemu-kvm' -nographic -version 2>/dev/null", ret=ret@entry=0x7f7868000910) at launch.c:1428
#5  0x00007f7881eaba04 in test_qemu (g=0x7f78680008c0) at launch.c:1410
#6  0x00007f7881eabaea in qemu_supports (g=g@entry=0x7f78680008c0, 
    option=option@entry=0x0) at launch.c:1479
#7  0x00007f7881eac921 in launch_appliance (g=g@entry=0x7f78680008c0)
    at launch.c:586
#8  0x00007f7881ead991 in guestfs__launch (g=g@entry=0x7f78680008c0)
    at launch.c:530
#9  0x00007f7881e4fda8 in guestfs_launch (g=g@entry=0x7f78680008c0)
    at actions.c:1119
#10 0x0000000000496ad8 in ocaml_guestfs_launch (gv=578721382704613384)
    at guestfs_c_actions.c:7544
#11 0x00000000004c3f9a in caml_c_call ()
#12 0x0000000000000001 in ?? ()

Unfortunately I have not been able to reproduce this bug in anything
smaller than my very large test case, which is why I'm asking if
anyone else has seen anything like this before.

  https://bugzilla.redhat.com/show_bug.cgi?id=838081

Rich.

-- 
Richard Jones
Red Hat

             reply	other threads:[~2012-07-16 12:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16 12:23 Richard W.M. Jones [this message]
2012-07-16 13:16 ` Richard W.M. Jones

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120716122327.GA16367@annexia.org \
    --to=rich@annexia.org \
    --cc=caml-list@inria.fr \
    /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 NNTP newsgroup(s).