gmane.comp.lang.go.general

Re: http.Get() becomes slow

Dave Cheney — 2013-06-20T01:43:17

Probably, patches welcome.

http://godoc.org/github.com/davecheney/loadavg

On Thu, Jun 20, 2013 at 11:40 AM, Carlos Castillo <cookieo9-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: http.Get() becomes slow

Carlos Castillo — 2013-06-20T01:40:23

Will this code also work for *BSD?

On 2013-06-19, at 6:34 PM, Dave Cheney <dave-7L4Cwp9BzA+sTnJN9+BGXg< at >public.gmane.org> wrote:

Re: http.Get() becomes slow

Dave Cheney — 2013-06-20T01:34:05

Yup, this is a bit of a bodge, but it'll work well enough for the OP
to validate their hypothesis that the loadavg is useful as a
throttling metric.

On Thu, Jun 20, 2013 at 11:32 AM, Carlos Castillo <cookieo9-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: http.Get() becomes slow

Carlos Castillo — 2013-06-20T01:32:43

My mistake, the "string" returned by syscall.Sysctl() is not just meant for
text, but to return a byte sequence, which can be (unsafe-ly) converted to
a struct of our choosing.


On Wed, Jun 19, 2013 at 6:21 PM, Dave Cheney <dave-7L4Cwp9BzA+sTnJN9+BGXg< at >public.gmane.org> wrote:

Re: http.Get() becomes slow

Dave Cheney — 2013-06-20T01:21:06

https://github.com/davecheney/loadavg

On Thu, Jun 20, 2013 at 10:45 AM, Carlos Castillo <cookieo9-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: suggestion about "go format": one line if statement

jimmy frasche — 2013-06-20T01:08:07

No, but I just don't like how crammed in it looks and I find it
distracting to read

If you're concerned about the length of the function you could
probably break it up into a few private helper functions that'll just
be (probably) inlined into the body as you wrote it originally.

Re: suggestion about "go format": one line if statement

Chris Broadfoot — 2013-06-20T01:06:03

func check(err error) {
  if err != nil {
    log.Fatal(err)
  }
}

c, err := ...
check(err)

This kind of error handling is quite lazy, so I'd generally recommend
against it. I'd use it in small programs, though, like when scripting.

On 20 Jun 2013 11:02, "dlin" <dlin.tw-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:
line.
"golang-nuts" group.
email to golang-nuts+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0< at >public.gmane.org

suggestion about "go format": one line if statement

dlin — 2013-06-20T01:02:45

In Go, we must write many error handle statement like:

c, err := ...
if err != nil { log.Fatal(err) }
n, err := ...
if err != nil { log.Fatal(err) }
...

But, when I use "go fmt", it will expand to
if err != nil { 
    log.Fatal(err) 
}

That let my function over one page long (25 lines).

So, if it possible don't expand one line in such case. 
If the one line is longer then 80 column, it is better to wrap as three 
line.
In my opinion, this way will keep code easier to read.

Any one agree this?

Re: http.Get() becomes slow

Carlos Castillo — 2013-06-20T00:45:26

Unfortunately, you can't use the sysctl method from go because the value 
you're looking to read "vm.loadavg", is a struct type, but go only supports 
string and int32 values. You could use CGO to do it correctly...

On Wednesday, June 19, 2013 2:20:27 PM UTC-7, Dave Cheney wrote:

Re: Segfault when switching to go 1.1 in c-land

Manoj Dayaram — 2013-06-20T00:04:29

Regardless, thanks for your help! Your stress script was essential in 
figuring this out ^.^


On Monday, June 17, 2013 4:09:50 PM UTC-7, Manoj Dayaram wrote:

After upgrading to go1.1, I keep getting a segfault during one of my go 
tests that uses c-code.  More specifically, this segfault takes place 
during the error handling code of libxml2.  Unfortunately, this segfault is 
not consistent, and will only surface after running the tests several 
times.  The test is not multithreaded.

Below are the steps to reproduce:

# Setup your environment.
/home/noj $> mkdir -p godev/src
/home/noj $> mkdir -p godev/clibs/src
/home/noj $> export GOPATH=`pwd`/godev
/home/noj $> go version
go version go1.1 darwin/amd64

# Clone gokogiri
/home/noj $> cd godev/src
/home/noj/godev/src $> git clone git-9UaJU3cA/F/QT0dZR+AlfA< at >public.gmane.org:moovweb/gokogiri
/home/noj/godev/src $> cd gokogiri; git checkout go1  # need to use go1 
branch

# Compile a test binary for the html package
/home/noj/godev/src $> cd gokogiri/html
/home/noj/godev/src/gokogiri/html $> go test -c -a .

# Run the test package multiple
/home/noj/godev/src/gokogiri/html $> while true; do ./html.test -test.v || 
break; done

Example segfault:

=== RUN TestUnfoundFuncInXpath
SIGSEGV: segmentation violation
PC=0x7fff826611ec
signal arrived during cgo execution

gokogiri/xpath._Cfunc_xmlXPathCompiledEval(0x1480cec0, 0x14808e40, 
0x44d8ca0)
gokogiri/xpath/_obj/_cgo_defun.c:81 +0x2f
gokogiri/xpath.(*XPath).Evaluate(0xc200083c70, 0x1480c780, 0xc200067e00, 
0x0, 0x0, ...)
gokogiri/xpath/_obj/_cgo_gotypes.go:620 +0xb0
gokogiri/xml.(*XmlNode).Search(0xc200067dc0, 0x412dfa0, 0xc200067e00, 0x0, 
0x0, ...)
gokogiri/xml/_obj/_cgo_gotypes.go:1362 +0x22a
gokogiri/xml.(*XmlNode).Search(0xc200067dc0, 0x40f1d20, 0xc200083c90, 0x0, 
0x0, ...)
gokogiri/xml/_obj/_cgo_gotypes.go:1354 +0x4bb
gokogiri/html.TestUnfoundFuncInXpath(0xc2000fd1b0)
/Users/noj/godev/src/gokogiri/html/xpath_test.go:16 +0x2bf
testing.tRunner(0xc2000fd1b0, 0x4247780)
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:353 +0x8a
created by testing.RunTests
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:433 +0x86b

goroutine 1 [chan receive]:
testing.RunTests(0x4196860, 0x4247600, 0x12, 0x12, 0x1, ...)
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:434 +0x88e
testing.Main(0x4196860, 0x4247600, 0x12, 0x12, 0x424a600, ...)
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:365 +0x8a
main.main()
gokogiri/html/_test/_testmain.go:77 +0x9a

goroutine 2 [syscall]:

goroutine 9 [finalizer wait]:
rax     0xb0187000
rbx     0x0
rcx     0xb0186990
rdx     0x4392ba8
rdi     0x0
rsi     0x7fff70e510b0
rbp     0xb0186320
rsp     0xb0186310
r8      0xb018688c
r9      0xb0186888
r10     0x44000
r11     0x7fff82611d84
r12     0x7fff70e510b0
r13     0x1480ce70
r14     0x4392ba8
r15     0x0
rip     0x7fff826611ec
rflags  0x10202
cs      0x2b
fs      0x0
gs      0x0


So what do we know?


   - This does not happen in go1.0.3 or below.
   - Libxml2 is compiled with multithread support by default (specifying 
   explicitly does not change anything).
   - The segfault always happens with the same stack trace (just not every 
   time).  Above you can see the Go stack trace.  Running the html.test file 
   using gdb will show you the C stack trace (the last bits vary per platform, 
   but is consistent within platform):
   

=== RUN TestUnfoundFuncInXpath

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000068
[Switching to process 46453 thread 0x1903]
0x00007fff826611ec in flockfile ()
(gdb) bt
#0  0x00007fff826611ec in flockfile ()
#1  0x00007fff8260cfa6 in vfprintf_l ()
#2  0x0000000004298b87 in xmlGenericErrorDefaultFunc (ctx=0x0, 
msg=0x4392ba8 "xmlXPathCompOpEval: function %s not found\n") at error.c:78
#3  0x00000000042f95ba in xmlXPathCompOpEval (ctxt=0xb0186a40, 
op=0xb0186a40) at xpath.c:13496
#4  0x00000000042fce08 in xmlXPathCompOpEvalToBoolean (ctxt=0x14903f60, 
op=0x158001c0, isPredicate=1) at xpath.c:14124
#5  0x00000000042fd1a1 in xmlXPathCompOpEvalPredicate (ctxt=0x14903f60, 
op=0x0, set=0xb0186ae0, contextSize=-1340575744, hasNsNodes=-1340577056) at 
xpath.c:11657
#6  0x00000000042fb74b in xmlXPathNodeCollectAndTest (ctxt=0x14903f60, 
op=0xb0186c20, first=0xb0186c20, last=0xb0186c20, toBool=-1340576736) at 
xpath.c:12524
#7  0x00000000042f92b2 in xmlXPathCompOpEval (ctxt=0xb0186cb0, 
op=0xb0186cb0) at xpath.c:13413
#8  0x00000000042fa095 in xmlXPathCompOpEval (ctxt=0xb0186d40, 
op=0xb0186d40) at xpath.c:13891
#9  0x00000000042fcff6 in xmlXPathRunEval (ctxt=0x14903f60, toBool=0) at 
xpath.c:14459
#10 0x00000000042ff8e8 in xmlXPathCompiledEvalInternal (comp=0x14990820, 
ctxt=0x149af4c0, resObj=0xb0186e18, toBool=0) at xpath.c:14819
#11 0x00000000042ffadb in xmlXPathCompiledEval (comp=0x14903f60, 
ctx=0x15800280) at xpath.c:14882


   - The invalid address that the program tries to access (0x68) is the 
   same across all platforms -- I've tested mac and linux.
   - The arguments to the function "xmlGenericErrorDefaultFunc" (the last C 
   function before kernel land) always seem valid upon entering, so the 
   corruption must be taking place elsewhere, possibly the heap?
   - Running these tests in go1.0.3 also calls the aforementioned function 
   with the same arguments but it returns without a segfault consistently
   - A simple program that performs the same actions as the test in 
   question does not segfault like the test does.
   

So, from my understanding, it appears to be some kind of memory corruption 
which is somewhat deterministic.  Unfortunately, gdb does not let me step 
into the kernel level functions where this segfault takes place, so it's 
hard to figure out exactly what gets corrupted.  I've done memory scans up 
and down the stack near that region as well as inspected all registers for 
the value 0x68 but didn't find anything.  Given that writing a small 
program with the same behavior does not crash, I get the feeling that this 
could be a go test issue?

It's also possible that we're just calculating a value incorrectly, and 
most of the times we end up with garbage that doesn't segfault, and only 
sometimes do we end up with garbage that does, in which case it would mean 
that the program is always doing the incorrect thing but we only notice it 
when it tries to access 0x68 specifically.

Anyways, I was wondering if anyone had any tips or suggestions on things to 
try.  I've been banging my head on this for over a week now with no 
results.  Any help would be appreciated.

Re: Re: Segfault when switching to go 1.1 in c-land

Manoj Dayaram — 2013-06-20T00:02:36

Hmm, that's odd that it would affect the behavior of the test run to that
degree then, that's assuming that go test doesn't spin off any go routines
while testing.

From what I can tell, it would **appear** like go test would run each test
file in a separate go routine, but tests within a test file are executed
serially....that's the way it appears given this example, but I don't have
enough info to say that for sure.

Manoj

//Manoj


On Wed, Jun 19, 2013 at 4:29 PM, Dave Cheney <dave-7L4Cwp9BzA+sTnJN9+BGXg< at >public.gmane.org> wrote:

Re: How multiply time.Duration by an integer?

Ian Lance Taylor — 2013-06-19T23:32:52

Right, thanks for the correction.

Ian

Re: Re: Segfault when switching to go 1.1 in c-land

Dave Cheney — 2013-06-19T23:29:07

In the same way GOMAXPROCS affects the behavior of any Go program, but
allowing more than one goroutine to execute in parallel. It doesn't
change the ordering of tests, or run tests concurrently.

I'm glad you have fixed your problem, I wasn't able to investigate
further due to the bug at tip, but my working hypothesis was the C
memory that libxml was not properly pinned on the G side, so was being
garbage collected behind the scenes. It was just a theory.

Re: Re: Segfault when switching to go 1.1 in c-land

Manoj Dayaram — 2013-06-19T23:24:46

Yup, not using t.Parallel anywhere.

But how does GOMAXPROCS affect the behavior of test execution?


//Manoj


On Wed, Jun 19, 2013 at 4:21 PM, Dave Cheney <dave-7L4Cwp9BzA+sTnJN9+BGXg< at >public.gmane.org> wrote:

Re: Re: Segfault when switching to go 1.1 in c-land

Dave Cheney — 2013-06-19T23:23:05

I do not believe that go test concurrently executes tests, unless you
use the t.Parallel flag, which you shouldn't, nobody should.

Re: Re: Segfault when switching to go 1.1 in c-land

Dave Cheney — 2013-06-19T23:21:47

Test cases are run in the order they are defined in the _test.go file.
If there are multiple _test.go files the overall ordering is not
specified.

GOMAXPROCS is a runtime value, it does not affect the value of
t.Parrallel. You shouldn't set t.Parallel, it is a very dangerous
switch that I wish was never added to go test.

Re: How multiply time.Duration by an integer?

peterGo — 2013-06-19T23:20:44

Correction:

Ian,

On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:
there are two type aliases in the language: byte is an alias for uint8, and 
rune is an alias for uint32.

Numeric types
http://golang.org/ref/spec#Numeric_types

rune        alias for int32

Peter

On Wednesday, June 19, 2013 7:14:17 PM UTC-4, peterGo wrote:

Re: How multiply time.Duration by an integer?

peterGo — 2013-06-19T23:14:17

Ian,

On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:On 
Wed, Jun 19, 2013 at 2:32 PM, RickyS <rickys...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote: 
there are two type aliases in the language: byte is an alias for uint8, and 
rune is an alias for uint32.

Numeric types
http://golang.org/ref/spec#Numeric_types

rune        alias for int32

Peter

On Wednesday, June 19, 2013 5:42:39 PM UTC-4, Ian Lance Taylor wrote:

Re: How multiply time.Duration by an integer?

William Kennedy — 2013-06-19T20:01:05

Hi Ricky,
Check out my blog on the subject, it might be of some help
http://www.goinggo.net/2013/06/gos-duration-type-unravelled.html

On Wednesday, June 19, 2013 9:22:44 AM UTC-4, RickyS wrote:

Re: Zero-downtime HTTP server in Go

2013-06-19T18:47:06

Falcore does what you're asking for and has been working in production for 
more than a year.  The hot_restart example shows how to hook into the 
lifecycle to do zero-downtime deploys.

http://github.com/fitstar/falcore

Scott



On Thursday, March 21, 2013 5:05:17 PM UTC-7, Manuel Amador wrote:

Re: Segfault when switching to go 1.1 in c-land

Manoj Dayaram — 2013-06-19T23:08:42

So I've figured out what causes the segfault.

It looks like each test is calling C.xmlCleanupParser(), however, according 
to libxml2 spec, that method should only be called once per the lifetime of 
the program and only once we're completely done parsing any document. 
 Altering the behavior of the test to skip that call fixes the issue.

I'm glad the segfault is fixed, but the issue regarding why go test 
defaults to concurrent execution still stands, is that the expected 
behavior?



On Monday, June 17, 2013 4:09:50 PM UTC-7, Manoj Dayaram wrote:

After upgrading to go1.1, I keep getting a segfault during one of my go 
tests that uses c-code.  More specifically, this segfault takes place 
during the error handling code of libxml2.  Unfortunately, this segfault is 
not consistent, and will only surface after running the tests several 
times.  The test is not multithreaded.

Below are the steps to reproduce:

# Setup your environment.
/home/noj $> mkdir -p godev/src
/home/noj $> mkdir -p godev/clibs/src
/home/noj $> export GOPATH=`pwd`/godev
/home/noj $> go version
go version go1.1 darwin/amd64

# Clone gokogiri
/home/noj $> cd godev/src
/home/noj/godev/src $> git clone git-9UaJU3cA/F/QT0dZR+AlfA< at >public.gmane.org:moovweb/gokogiri
/home/noj/godev/src $> cd gokogiri; git checkout go1  # need to use go1 
branch

# Compile a test binary for the html package
/home/noj/godev/src $> cd gokogiri/html
/home/noj/godev/src/gokogiri/html $> go test -c -a .

# Run the test package multiple
/home/noj/godev/src/gokogiri/html $> while true; do ./html.test -test.v || 
break; done

Example segfault:

=== RUN TestUnfoundFuncInXpath
SIGSEGV: segmentation violation
PC=0x7fff826611ec
signal arrived during cgo execution

gokogiri/xpath._Cfunc_xmlXPathCompiledEval(0x1480cec0, 0x14808e40, 
0x44d8ca0)
gokogiri/xpath/_obj/_cgo_defun.c:81 +0x2f
gokogiri/xpath.(*XPath).Evaluate(0xc200083c70, 0x1480c780, 0xc200067e00, 
0x0, 0x0, ...)
gokogiri/xpath/_obj/_cgo_gotypes.go:620 +0xb0
gokogiri/xml.(*XmlNode).Search(0xc200067dc0, 0x412dfa0, 0xc200067e00, 0x0, 
0x0, ...)
gokogiri/xml/_obj/_cgo_gotypes.go:1362 +0x22a
gokogiri/xml.(*XmlNode).Search(0xc200067dc0, 0x40f1d20, 0xc200083c90, 0x0, 
0x0, ...)
gokogiri/xml/_obj/_cgo_gotypes.go:1354 +0x4bb
gokogiri/html.TestUnfoundFuncInXpath(0xc2000fd1b0)
/Users/noj/godev/src/gokogiri/html/xpath_test.go:16 +0x2bf
testing.tRunner(0xc2000fd1b0, 0x4247780)
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:353 +0x8a
created by testing.RunTests
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:433 +0x86b

goroutine 1 [chan receive]:
testing.RunTests(0x4196860, 0x4247600, 0x12, 0x12, 0x1, ...)
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:434 +0x88e
testing.Main(0x4196860, 0x4247600, 0x12, 0x12, 0x424a600, ...)
/Users/noj/.gvm/gos/go1.1/src/pkg/testing/testing.go:365 +0x8a
main.main()
gokogiri/html/_test/_testmain.go:77 +0x9a

goroutine 2 [syscall]:

goroutine 9 [finalizer wait]:
rax     0xb0187000
rbx     0x0
rcx     0xb0186990
rdx     0x4392ba8
rdi     0x0
rsi     0x7fff70e510b0
rbp     0xb0186320
rsp     0xb0186310
r8      0xb018688c
r9      0xb0186888
r10     0x44000
r11     0x7fff82611d84
r12     0x7fff70e510b0
r13     0x1480ce70
r14     0x4392ba8
r15     0x0
rip     0x7fff826611ec
rflags  0x10202
cs      0x2b
fs      0x0
gs      0x0


So what do we know?


   - This does not happen in go1.0.3 or below.
   - Libxml2 is compiled with multithread support by default (specifying 
   explicitly does not change anything).
   - The segfault always happens with the same stack trace (just not every 
   time).  Above you can see the Go stack trace.  Running the html.test file 
   using gdb will show you the C stack trace (the last bits vary per platform, 
   but is consistent within platform):
   

=== RUN TestUnfoundFuncInXpath

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000068
[Switching to process 46453 thread 0x1903]
0x00007fff826611ec in flockfile ()
(gdb) bt
#0  0x00007fff826611ec in flockfile ()
#1  0x00007fff8260cfa6 in vfprintf_l ()
#2  0x0000000004298b87 in xmlGenericErrorDefaultFunc (ctx=0x0, 
msg=0x4392ba8 "xmlXPathCompOpEval: function %s not found\n") at error.c:78
#3  0x00000000042f95ba in xmlXPathCompOpEval (ctxt=0xb0186a40, 
op=0xb0186a40) at xpath.c:13496
#4  0x00000000042fce08 in xmlXPathCompOpEvalToBoolean (ctxt=0x14903f60, 
op=0x158001c0, isPredicate=1) at xpath.c:14124
#5  0x00000000042fd1a1 in xmlXPathCompOpEvalPredicate (ctxt=0x14903f60, 
op=0x0, set=0xb0186ae0, contextSize=-1340575744, hasNsNodes=-1340577056) at 
xpath.c:11657
#6  0x00000000042fb74b in xmlXPathNodeCollectAndTest (ctxt=0x14903f60, 
op=0xb0186c20, first=0xb0186c20, last=0xb0186c20, toBool=-1340576736) at 
xpath.c:12524
#7  0x00000000042f92b2 in xmlXPathCompOpEval (ctxt=0xb0186cb0, 
op=0xb0186cb0) at xpath.c:13413
#8  0x00000000042fa095 in xmlXPathCompOpEval (ctxt=0xb0186d40, 
op=0xb0186d40) at xpath.c:13891
#9  0x00000000042fcff6 in xmlXPathRunEval (ctxt=0x14903f60, toBool=0) at 
xpath.c:14459
#10 0x00000000042ff8e8 in xmlXPathCompiledEvalInternal (comp=0x14990820, 
ctxt=0x149af4c0, resObj=0xb0186e18, toBool=0) at xpath.c:14819
#11 0x00000000042ffadb in xmlXPathCompiledEval (comp=0x14903f60, 
ctx=0x15800280) at xpath.c:14882


   - The invalid address that the program tries to access (0x68) is the 
   same across all platforms -- I've tested mac and linux.
   - The arguments to the function "xmlGenericErrorDefaultFunc" (the last C 
   function before kernel land) always seem valid upon entering, so the 
   corruption must be taking place elsewhere, possibly the heap?
   - Running these tests in go1.0.3 also calls the aforementioned function 
   with the same arguments but it returns without a segfault consistently
   - A simple program that performs the same actions as the test in 
   question does not segfault like the test does.
   

So, from my understanding, it appears to be some kind of memory corruption 
which is somewhat deterministic.  Unfortunately, gdb does not let me step 
into the kernel level functions where this segfault takes place, so it's 
hard to figure out exactly what gets corrupted.  I've done memory scans up 
and down the stack near that region as well as inspected all registers for 
the value 0x68 but didn't find anything.  Given that writing a small 
program with the same behavior does not crash, I get the feeling that this 
could be a go test issue?

It's also possible that we're just calculating a value incorrectly, and 
most of the times we end up with garbage that doesn't segfault, and only 
sometimes do we end up with garbage that does, in which case it would mean 
that the program is always doing the incorrect thing but we only notice it 
when it tries to access 0x68 specifically.

Anyways, I was wondering if anyone had any tips or suggestions on things to 
try.  I've been banging my head on this for over a week now with no 
results.  Any help would be appreciated.