Grokbase › Groups › Go › golang-dev › June 2013
FAQ

On Fri, Jun 14, 2013 at 3:33 PM, wrote:
As a side-note: this caused a severe performance regression on an old,
unsupported, release of FreeBSD (7.0 plus security patches), such that
running "go version" would take 60 seconds to complete (or 5 seconds
under ktrace). It appears, from kdump, that the code enters a tight
loop with 441,722 instances of "_umtx_op -1 errno 22 Invalid argument"
in the output, and the same parameters passed every time.

Since the code supporting UMTX_OP_WAIT_UINT went into FreeBSD in 2007 (
http://svnweb.freebsd.org/base?view=revision&revision=173800 ), I
suspect that leaving this change in Go is correct, but perhaps there
could be some better error detection?

Reverting this change resolved the issues for me.
The code is os_freebsd.c is intended to crash if the system call
fails. It looks correct to me but I guess it isn't. I don't think we
care about a version of FreeBSD from before 2007, but if you can work
up a patch that detects the error correctly--i.e., crashes--we can
probably commit it.

Ian

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Syscomet at Jun 15, 2013 at 12:09 am ⇧

    On 2013/04/12 12:20:23, iant wrote:
    *** Submitted as
    https://code.google.com/p/go/source/detail?r=64bd7ce0c817 ***
    runtime: use UMTX_OP_WAIT_UINT on FreeBSD
    UMTX_OP_WAIT expects that the address points to a uintptr, but
    the code in lock_futex.c uses a uint32. UMTX_OP_WAIT_UINT is
    just like UMTX_OP_WAIT, but the address points to a uint32.
    This almost certainly makes no difference on a little-endian
    system, but since the kernel supports it we should do the
    right thing. And, who knows, maybe it matters.
    As a side-note: this caused a severe performance regression on an old,
    unsupported, release of FreeBSD (7.0 plus security patches), such that
    running "go version" would take 60 seconds to complete (or 5 seconds
    under ktrace). It appears, from kdump, that the code enters a tight
    loop with 441,722 instances of "_umtx_op -1 errno 22 Invalid argument"
    in the output, and the same parameters passed every time.

    Since the code supporting UMTX_OP_WAIT_UINT went into FreeBSD in 2007 (
    http://svnweb.freebsd.org/base?view=revision&revision=173800 ), I
    suspect that leaving this change in Go is correct, but perhaps there
    could be some better error detection?

    Reverting this change resolved the issues for me.

    https://codereview.appspot.com/8699043/

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Devon H. O'Dell at Jun 15, 2013 at 2:30 am ⇧

    2013/6/14 Ian Lance Taylor <iant@golang.org>:
    On Fri, Jun 14, 2013 at 3:33 PM, wrote:

    As a side-note: this caused a severe performance regression on an old,
    unsupported, release of FreeBSD (7.0 plus security patches), such that
    running "go version" would take 60 seconds to complete (or 5 seconds
    under ktrace). It appears, from kdump, that the code enters a tight
    loop with 441,722 instances of "_umtx_op -1 errno 22 Invalid argument"
    in the output, and the same parameters passed every time.

    Since the code supporting UMTX_OP_WAIT_UINT went into FreeBSD in 2007 (
    http://svnweb.freebsd.org/base?view=revision&revision=173800 ), I
    suspect that leaving this change in Go is correct, but perhaps there
    could be some better error detection?

    Reverting this change resolved the issues for me.
    The code is os_freebsd.c is intended to crash if the system call
    fails. It looks correct to me but I guess it isn't. I don't think we
    care about a version of FreeBSD from before 2007, but if you can work
    up a patch that detects the error correctly--i.e., crashes--we can
    probably commit it.
    I am not sure that 7 was ever explicitly supported. The original port
    was developed on FreeBSD 8, and there were a few bits (pkg/net,
    maybe?) that had kqueue / other system needs that weren't in 7 (if I
    recall correctly -- it's possible I don't, it's been almost 4 years
    now).

    I'm surprised the *(int32*)1005=0x1005 doesn't cause a crash. If
    that's not crashing, it would be good to figure out why ktrace shows
    it returning EINVAL and that line not running. I don't have a FreeBSD
    7 machine to try this out on.

    --dho
    Ian

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Jun 15, 2013 at 6:14 am ⇧

    On Sat, Jun 15, 2013 at 10:30 AM, Devon H. O'Dell wrote:

    I'm surprised the *(int32*)1005=0x1005 doesn't cause a crash. If
    that's not crashing, it would be good to figure out why ktrace shows
    it returning EINVAL and that line not running. I don't have a FreeBSD
    7 machine to try this out on.
    It's because the returned AX contains the errno value but it's positive.

    Hi @syscomet, could you please patch in
    https://codereview.appspot.com/10295043
    and see if you got an error when executing on FreeBSD 7?

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Devon H. O'Dell at Jun 15, 2013 at 7:50 am ⇧
    2013/6/15 minux <minux.ma@gmail.com>:
    On Sat, Jun 15, 2013 at 10:30 AM, Devon H. O'Dell wrote:

    I'm surprised the *(int32*)1005=0x1005 doesn't cause a crash. If
    that's not crashing, it would be good to figure out why ktrace shows
    it returning EINVAL and that line not running. I don't have a FreeBSD
    7 machine to try this out on.
    It's because the returned AX contains the errno value but it's positive.
    There may be other cases then. I haven't checked, but I'm reasonably
    sure that's not the only one. That means the EINTR check is bad, too.
    Hi @syscomet, could you please patch in
    https://codereview.appspot.com/10295043
    and see if you got an error when executing on FreeBSD 7?
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Devon H. O'Dell at Jun 15, 2013 at 7:50 am ⇧

    2013/6/15 Devon H. O'Dell <devon.odell@gmail.com>:
    2013/6/15 minux <minux.ma@gmail.com>:
    On Sat, Jun 15, 2013 at 10:30 AM, Devon H. O'Dell <devon.odell@gmail.com>
    wrote:
    I'm surprised the *(int32*)1005=0x1005 doesn't cause a crash. If
    that's not crashing, it would be good to figure out why ktrace shows
    it returning EINVAL and that line not running. I don't have a FreeBSD
    7 machine to try this out on.
    It's because the returned AX contains the errno value but it's positive.
    There may be other cases then. I haven't checked, but I'm reasonably
    sure that's not the only one. That means the EINTR check is bad, too.
    Actually, it means the ret >= 0 check is bad in general.
    Hi @syscomet, could you please patch in
    https://codereview.appspot.com/10295043
    and see if you got an error when executing on FreeBSD 7?
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJun 14, '13 at 11:17p
activeJun 15, '13 at 7:50a
posts6
users4
websitegolang.org

4 users in discussion

Devon H. O'Dell: 3 posts Ian Lance Taylor: 1 post Syscomet: 1 post Minux: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase