[go-nuts] Re: DialTLS + Context with http Transport

[Joshua Boelter]

Depending on what you're trying to do, this might get you further

https://github.com/golang/go/blob/46f4bfb2d17a3ccb4b3207d086a90cac3c00ea2f/src/crypto/tls/common.go#L417
https://github.com/golang/go/issues/16363

On Thursday, August 17, 2017 at 3:33:14 PM UTC-7, Gabriel Rosenhouse wrote:
>
> Hello,
>
> We're trying to configure a http.Transport such that the client does extra 
> validation of the server-provided certificate before sending any data. We 
> want this client to compare server-provided certificate fields against 
> values present on the request Context.  In essence, we'd like to be able to 
> write:
>
> tr := http.Transport{
>   DialTLSContext: func(ctx context.Context, network, addr string) (net.
> Conn, err) {
> conn, err := tls.Dial(network, addr, myConfig)
> if err != nil {
>   return err
> }
> connState := conn.(*tls.Conn).ConnectionState()
> ok := extraValidation(connState, ctx)
> if !ok {
>   return nil, errors.New("extra validation failed")
> }
> return conn
>   },
> }
>
> But DialTLSContext doesn't exist today.  We see Transport.DialContext(), 
> but if you try to tls.Dial() inside there while leaving DialTLS nil, the 
> http.Transport won't know that the conn is already TLS, and it will attempt 
> to TLS handshake again [0]
>
> Could anyone suggest a workaround for this, short of modifying the 
> `http.Transport` source code itself?
>
> Thank you,
>
> Gabe Rosenhouse
>
> [0] https://golang.org/src/net/http/transport.go#L1063
>

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

Re: [go-nuts] Re: [ANN] Gop - Build and manage your Go applications out of GOPATH

[Maurizio Vitale]

Not everybody wants to accept that all projects have to live under a unique
GOPATH.

For instance I want to be able to clone a project and build it wherever I
want. I might even want to have more than one sandbox with the same
project. Or golang projects that are deep inside another project tree.
I achieve this by building inside a container (so in a sense inside the
container GOPATH is as the golang gods intended it). I tried other
approaches (like multiple directories in GOPATH), but ended up having even
more problems.
I still have a few problems with some tools, but mostly because I didn't
spend enough time to containerize them.

On Fri, Aug 18, 2017 at 6:43 AM, Fino  wrote:

> Hello,
>
> Can I ask for a typical use case?
>
> BR fino
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7fcb5ae54390

[Ian Lance Taylor]

On Fri, Aug 18, 2017 at 5:36 PM, Justin Israel  wrote:
>
> I have cgo code that looks like this in a few of my own libs and I just
> started seeing crashes like this as of Go 1.8. Could it be related to the
> need for using runtime.KeepAlive? I have been adding that to my functions
> that look like this

As a general guideline, the only code that should require
runtime.KeepAlive is code that uses runtime.SetFinalizer.  If you
never use SetFinalizer, you should not need to use KeepAlive.

Either way, memory allocated by C.CString or C.malloc will never be
touched by the Go garbage collector, and using runtime.KeepAlive on it
will not have any effect.

Ian

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

Re: [go-nuts] signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7fcb5ae54390

[Justin Israel]

On Sat, Aug 19, 2017, 8:38 AM Ian Lance Taylor  wrote:

> On Fri, Aug 18, 2017 at 8:59 AM, Bhaskar Singhal
>  wrote:
> >
> > C function just copies the parameters passed. All of the params have
> escaped
> > to heap as seen in output generated by using -gcflags "-m -m" during
> build.
> >
> > I am trying to figure out if there is a possibility that gc frees any of
> > these parameters before the C function call returns.
>
> Go's garbage collector never frees memory allocated by C.CString, just
> as it never frees memory allocated by C.malloc.
>
> Ian
>
>
> > On Fri, Aug 18, 2017 at 7:57 PM, Ian Lance Taylor 
> wrote:
> >>
> >> On Fri, Aug 18, 2017 at 12:53 AM, Bhaskar Singhal
> >>  wrote:
> >> > I am running into a seg fault. The code keeps crashing either due to
> >> > unexpected signal or double free.
> >> >
> >> > Any pointers on what I am doing wrong here:
> >> >
> >> > Code Snippet:
> >> > // Put puts the given key / value to the kvstore
> >> > func (kvs *kvstore) Put(key []byte, value []byte) error {
> >> > /* Encode key to avoid null characters in byte[] */
> >> > strk := base64.StdEncoding.EncodeToString([]byte(key))
> >> > csk := C.CString(strk)
> >> > defer C.free(unsafe.Pointer(csk))
> >> >
> >> > /* Encode value to avoid null characters in byte[] */
> >> > strv := base64.StdEncoding.EncodeToString([]byte(value))
> >> > csv := C.CString(strv)
> >> > defer C.free(unsafe.Pointer(csv))
> >> >
> >> > if kvs.kvtree == nil {
> >> > return fmt.Errorf("put failed because kvtree is nil")
> >> > }
> >> > size := C.int32_t(len(strv))
> >> >
> >> > ret := C.put(kvs.kvtree, csk, csv, )
> >> > if ret != C.int8_t(1) {
> >> > return fmt.Errorf("kvtree put failed %g", ret)
> >> > }
> >> > return nil
> >> > }
> >> >
> >> > C Function Put:
> >> > int8_t put(KVTree* kv,
> >> >   const char* key,
> >> >   const char* value,
> >> >   const int32_t* valuebytes);
> >>
> >>
> >> It really depends on how the C function behaves.  My guess is that it
> >> does not expect the values to be freed.
> >>
> >> Ian
> >
> >
>

I have cgo code that looks like this in a few of my own libs and I just
started seeing crashes like this as of Go 1.8. Could it be related to the
need for using runtime.KeepAlive? I have been adding that to my functions
that look like this


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

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

RE: [go-nuts] Go channels overused and hyped?

[John Souvestre]

Interesting.  So you think it is a general safety advisory (which would apply 
to any language) to use synchronization (ex: mutex or channel) and not a more 
focused push to use channels?  Hmmm...  I didn't understand it that way.  I 
thought that "communicate" was a reference to the "C" in CSP.  It never crossed 
my mind that it would mean "use synchronization".

The context of the Go FAQ section which includes the proverb discourages 
mutexes (with no mention of when they should or should not be used).  The two 
links it provides bolster this and only provide examples using channels.

The wiki article MutexOrChannel starts off with the proverb then immediately 
follows with "That said, Go does provide traditional locking mechanisms in the 
sync package."  Why the need to say this if the moto was meant to include the 
sync methods, too?

Everything I recall reading or listening to which references the proverb seems 
to continue in this theme to avoid locking.  Here's a rather explicit one from 
https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions: " Don’t 
communicate by sharing memory, share memory by communicating.  Our first 
proverb–don’t mediate access to shared memory with locks and mutexes, instead 
share that memory by communicating."

Also, in Rob Pike's talk "Go Proverbs" at Gopherfest on 11/18/2015 he talks 
about this proverb.  He defines "sharing memory by communicating" as "passing 
on a channel the address of a data structure or an object ...".

So I don't think that I'm alone in thinking that the focus of the proverb is to 
use channels to share memory, rather than any other way.  And I find this 
somewhat wrong and certainly confusing.  Am I really alone in this?  

John

John Souvestre - New Orleans LA


-Original Message-
From: Ian Lance Taylor [mailto:i...@golang.org] 
Sent: 2017 August 18, Fri 15:14
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Go channels overused and hyped?

On Fri, Aug 18, 2017 at 12:02 PM, John Souvestre  wrote:
>
> I think that both of the suggestions below are great.  But I�m left
> wondering about the Go mantra
>
>
>
> Do not communicate by sharing memory. Instead, share memory by
> communicating.
>
>
>
> What does it say?  It starts off with communicating as the goal, but doesn�t
> tell you how to do it.  Then sharing memory is the goal and the solution it
> provides (communicating) is only right some of the time.
>
>
>
> Am I missing something?  Should this be replaced?

As I see it, the point of the proverb is to focus on having goroutines
use explicit communication mechanisms, such as channels and mutexes,
to hand control of an area of memory over to another goroutine.  An
example of communicating by sharing memory would having one goroutine
poll a memory location that is then changed by a different goroutine.
As a general guideline, prefer explicit communication mechanisms.

Ian

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

Re: [go-nuts] Re: Is this bad concurrency?

[Josh Humphries]

There's not a way to terminate a goroutine. But you can create a context
with cancellation. Each goroutine would need to periodically check
context.Err() and exit on its own.

When you exit, you cancel the context. You could combine this with a
WaitGroup in order to not exit until all other goroutines have completed
(e.g. cancel the context and then await, provided you've added to the wait
group for each task and each one marks their work as done on completion).


*Josh Humphries*
jh...@bluegosling.com

On Fri, Aug 18, 2017 at 5:19 PM,  wrote:

> Thanks to both for replying. Both pieces of advice cover the use case of
> waiting for all goroutines to complete before exiting. I have the opposite
> problem. I want to end all goroutines if I exit. Is there anything in the
> sync package for that?
>
>
> On Friday, August 18, 2017 at 2:40:39 PM UTC-4, Tamás Gulácsi wrote:
>>
>> See golang.org/x/sync/errgroup.WithContext.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: Is this bad concurrency?

[bill . warner]

Thanks to both for replying. Both pieces of advice cover the use case of 
waiting for all goroutines to complete before exiting. I have the opposite 
problem. I want to end all goroutines if I exit. Is there anything in the 
sync package for that?

On Friday, August 18, 2017 at 2:40:39 PM UTC-4, Tamás Gulácsi wrote:
>
> See golang.org/x/sync/errgroup.WithContext.

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

Re: [go-nuts] multiply and divide

[Michael Jones]

Integer is a different matter because of truncation. The order is
significant.

Floating point is tricky there. the fractional parts can be multiplied in
any order in terms of precision. however, the exponents add so best of all
would be a kind of alternating summation that keeps them in the +/- 308
range. (1e200 * 1e-199 * 1e180 * 1e-170 and so on).

basically...it would be nicer if they were real numbers. :-)

On Fri, Aug 18, 2017 at 11:49 AM, John Souvestre  wrote:

> Ø  "multiply first, then divide."
>
>
>
> While often the right method, I don’t think that it always is.  Consider:
>
> -Integer:  It is as long as the product doesn’t overflow (before the
> divide).
>
> -Floating:  I’m inclined to think that combining numbers of the same
> magnitude first might be a better approach.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *Michael Jones
> *Sent:* 2017 August 18, Fri 11:50
> *To:* golang-nuts
> *Subject:* [go-nuts] multiply and divide
>
>
>
> Here is a minor musing from something that came up yesterday.
>
>
>
> Sometimes we see a real number expression as simple as...
>
>
>
>   x*y/z
>
>
>
> ...and knowing from basic algebra that...
>
>
>
> (x*y)/z == x*(y/z)
>
>
>
> ...we might not expect much difference between the two in our code. Alas,
> computer floating point does not involve real numbers, rather it uses an
> approximation of them. If you will copy https://play.golang.org/
> p/IlDxtvx7IY to your computer, build and run it, (too much CPU for the
> playground) you'll find that the order makes a difference. Or, you can just
> remember this phrase, "multiply first, then divide."
>
>
>
> --
>
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7fcb5ae54390

[Ian Lance Taylor]

On Fri, Aug 18, 2017 at 8:59 AM, Bhaskar Singhal
 wrote:
>
> C function just copies the parameters passed. All of the params have escaped
> to heap as seen in output generated by using -gcflags "-m -m" during build.
>
> I am trying to figure out if there is a possibility that gc frees any of
> these parameters before the C function call returns.

Go's garbage collector never frees memory allocated by C.CString, just
as it never frees memory allocated by C.malloc.

Ian


> On Fri, Aug 18, 2017 at 7:57 PM, Ian Lance Taylor  wrote:
>>
>> On Fri, Aug 18, 2017 at 12:53 AM, Bhaskar Singhal
>>  wrote:
>> > I am running into a seg fault. The code keeps crashing either due to
>> > unexpected signal or double free.
>> >
>> > Any pointers on what I am doing wrong here:
>> >
>> > Code Snippet:
>> > // Put puts the given key / value to the kvstore
>> > func (kvs *kvstore) Put(key []byte, value []byte) error {
>> > /* Encode key to avoid null characters in byte[] */
>> > strk := base64.StdEncoding.EncodeToString([]byte(key))
>> > csk := C.CString(strk)
>> > defer C.free(unsafe.Pointer(csk))
>> >
>> > /* Encode value to avoid null characters in byte[] */
>> > strv := base64.StdEncoding.EncodeToString([]byte(value))
>> > csv := C.CString(strv)
>> > defer C.free(unsafe.Pointer(csv))
>> >
>> > if kvs.kvtree == nil {
>> > return fmt.Errorf("put failed because kvtree is nil")
>> > }
>> > size := C.int32_t(len(strv))
>> >
>> > ret := C.put(kvs.kvtree, csk, csv, )
>> > if ret != C.int8_t(1) {
>> > return fmt.Errorf("kvtree put failed %g", ret)
>> > }
>> > return nil
>> > }
>> >
>> > C Function Put:
>> > int8_t put(KVTree* kv,
>> >   const char* key,
>> >   const char* value,
>> >   const int32_t* valuebytes);
>>
>>
>> It really depends on how the C function behaves.  My guess is that it
>> does not expect the values to be freed.
>>
>> Ian
>
>

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

Re: [go-nuts] Go channels overused and hyped?

[Ian Lance Taylor]

On Fri, Aug 18, 2017 at 12:02 PM, John Souvestre  wrote:
>
> I think that both of the suggestions below are great.  But I’m left
> wondering about the Go mantra
>
>
>
> Do not communicate by sharing memory. Instead, share memory by
> communicating.
>
>
>
> What does it say?  It starts off with communicating as the goal, but doesn’t
> tell you how to do it.  Then sharing memory is the goal and the solution it
> provides (communicating) is only right some of the time.
>
>
>
> Am I missing something?  Should this be replaced?

As I see it, the point of the proverb is to focus on having goroutines
use explicit communication mechanisms, such as channels and mutexes,
to hand control of an area of memory over to another goroutine.  An
example of communicating by sharing memory would having one goroutine
poll a memory location that is then changed by a different goroutine.
As a general guideline, prefer explicit communication mechanisms.

Ian

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

[go-nuts] Re: transport: http2Server.HandleStreams failed to read frame: read tcp 192.168.56.1:8080->192.168.56.1:29065: wsarecv: An existing connection was forcibly closed by the remote host.

[rashit . khamidullin]

Hello Nikhli, have you solved the issue?

вторник, 17 января 2017 г., 6:36:13 UTC+3 пользователь Nikhil Tathe написал:
>
> Hi all,
> I am building a grpc server client communication on windows.
> I am getting error as 
> transport: http2Server.HandleStreams failed to read frame: read tcp 
> 192.168.56.1:8080->192.168.56.1:29065: wsarecv: An existing connection 
> was forcibly closed by the remote host.
> I am not able understand it.
> I googled about it but I no luck.
>
> I tried grpc sample code from 
> https://github.com/grpc/grpc-go/tree/master/examples/helloworld/ on my 
> system
> still getting similar error
> transport: http2Server.HandleStreams failed to read frame: read tcp [::1]:
> 50051->[::1]:28563: wsarecv: An existing connection was forcibly closed by 
> the remote host.
>
> Server code:
> package main
>
> import (
> "log"
> "net"
>
> "golang.org/x/net/context"
> "google.golang.org/grpc"
> pb "google.golang.org/grpc/examples/helloworld/helloworld"
> "google.golang.org/grpc/reflection"
> )
>
> const (
> port = ":50051"
> )
>
> // server is used to implement helloworld.GreeterServer.
> type server struct{}
>
> // SayHello implements helloworld.GreeterServer
> func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.
> HelloReply, error) {
> return {Message: "Hello " + in.Name}, nil
> }
>
> func main() {
> lis, err := net.Listen("tcp", port)
> if err != nil {
> log.Fatalf("failed to listen: %v", err)
> }
> s := grpc.NewServer()
> pb.RegisterGreeterServer(s, {})
> // Register reflection service on gRPC server.
> reflection.Register(s)
> if err := s.Serve(lis); err != nil {
> log.Fatalf("failed to serve: %v", err)
> }
> }
>
> Client code 
> package main
>
> import (
> "log"
> "os"
>
> "golang.org/x/net/context"
> "google.golang.org/grpc"
> pb "google.golang.org/grpc/examples/helloworld/helloworld"
> )
>
> const (
> address = "localhost:50051"
> defaultName = "world"
> )
>
> func main() {
> // Set up a connection to the server.
> conn, err := grpc.Dial(address, grpc.WithInsecure())
> if err != nil {
> log.Fatalf("did not connect: %v", err)
> }
> defer conn.Close()
> c := pb.NewGreeterClient(conn)
>
> // Contact the server and print out its response.
> name := defaultName
> if len(os.Args) > 1 {
> name = os.Args[1]
> }
> r, err := c.SayHello(context.Background(), {Name: name
> })
> if err != nil {
> log.Fatalf("could not greet: %v", err)
> }
> log.Printf("Greeting: %s", r.Message)
> }
>
>
> I found something on googling as 
> https://go.googlesource.com/net/+/master/http2/server.go
> https://golang.org/src/net/http/h2_bundle.go
>
> which tells problem is Windows OS specific.
> Not able to understand and find solution for it.
>
> if runtime.GOOS == "windows" {
>
> if oe, ok := err.(*net.OpError); ok && oe.Op == "read" {
>
> if se, ok := oe.Err.(*os.SyscallError); ok && se.Syscall == 
> "wsarecv" {
>
> const WSAECONNABORTED = 10053
>
> const WSAECONNRESET = 10054
>
> if n := http2errno(se.Err); n == WSAECONNRESET || n == 
> WSAECONNABORTED {
>
> return true
>
> }
>
> }
>
> }
>
> }
>
>
> Can anyone help me out in it ?
>
>

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

RE: [go-nuts] Go channels overused and hyped?

[John Souvestre]

P.S.

 

And if you want to reduce it to a one-liner, how about this?

 

Communicating is better than sharing sometimes, and vice versa.

 

John

John Souvestre - New Orleans LA

 

From: John Souvestre [mailto:j...@souvestre.com] 
Sent: 2017 August 18, Fri 14:03
To: 'golang-nuts'
Subject: RE: [go-nuts] Go channels overused and hyped?

 

I think that both of the suggestions below are great.  But I’m left wondering 
about the Go mantra

 

Do not communicate by sharing memory. Instead, share memory by 
communicating.

 

What does it say?  It starts off with communicating as the goal, but doesn’t 
tell you how to do it.  Then sharing memory is the goal and the solution it 
provides (communicating) is only right some of the time.

 

Am I missing something?  Should this be replaced?

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Michael Jones
Sent: 2017 August 18, Fri 08:57
To: Tamás Gulácsi
Cc: golang-nuts
Subject: Re: [go-nuts] Go channels overused and hyped?

 

yes... everything is good for what it is designed for and less-good for what it 
is not designed for.

 

mutex-protected counters are good

channels for data communication are good

 

neither is a perfect stand in for the other. nothin wrong with channels.

 

On Fri, Aug 18, 2017 at 4:38 AM, Tamás Gulácsi  wrote:

No. Use channels to coordinate and send data between goroutines, and other sync 
primitives to coordinate access to shared resources. Both has its pros and 
cons, use the best tool for the job.


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





 

-- 

Michael T. Jones
michael.jo...@gmail.com

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

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

RE: [go-nuts] multiply and divide

[John Souvestre]

Ø  "multiply first, then divide." 

 

While often the right method, I don’t think that it always is.  Consider:

-Integer:  It is as long as the product doesn’t overflow (before the 
divide).

-Floating:  I’m inclined to think that combining numbers of the same 
magnitude first might be a better approach.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Michael Jones
Sent: 2017 August 18, Fri 11:50
To: golang-nuts
Subject: [go-nuts] multiply and divide

 

Here is a minor musing from something that came up yesterday.

 

Sometimes we see a real number expression as simple as...

 

  x*y/z

 

...and knowing from basic algebra that...

 

(x*y)/z == x*(y/z)

 

...we might not expect much difference between the two in our code. Alas, 
computer floating point does not involve real numbers, rather it uses an 
approximation of them. If you will copy https://play.golang.org/p/IlDxtvx7IY to 
your computer, build and run it, (too much CPU for the playground) you'll find 
that the order makes a difference. Or, you can just remember this phrase, 
"multiply first, then divide." 

 

-- 

Michael T. Jones
michael.jo...@gmail.com

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

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

RE: [go-nuts] Is this bad concurrency?

[John Souvestre]

You might want to consider using a sync.WaitGroup.  It’s for such situations.

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of bill.war...@talentinc.com
Sent: 2017 August 18, Fri 13:01
To: golang-nuts
Subject: [go-nuts] Is this bad concurrency?

 

Hi,

 

https://play.golang.org/p/lR6_mxSjtb

 

I have two long running things to do, I'd like to do them in parallel, then 
sync up at the end. I've written it as a function which gets one thing done, 
and which backgrounds the second thing with a goroutine. Thing one has a lot of 
reasons to exit early, and I need to signal those to thing two so that the go 
routine can exit cleanly and not create a goroutine leak. Standard fare, 
usually solved by introducing a channel and a select statement. I want to 
signal done for early exits, including panics,  so I thought I would write to 
the done channel in a defer block. That caused a problem, because in the happy 
case, both the foreground and the background routines are finished, the done 
channel has no reader, so writing to it in the defer block causes "fatal error: 
all goroutines are asleep - deadlock!" So I introduced a new boolean variable 
("clean_finish") that is false until the background job completes, and which is 
tested in the defer block before writing to the done channel. Is there anything 
wrong with my approach? You can see the code in the playground link above, or 
down below.

 

 

package main

 

import (

"sync/atomic"

"fmt"

"time"

)

 

func main() {

ch := make(chan int)

done := make(chan struct{})

var clean_finish uint32

defer func() {  

fin := atomic.LoadUint32(_finish)

if fin != 1 {

done <- struct{}{}

}

}()

go func() {

defer func() {

fmt.Println("we're done here")

}()

select {

case <-time.After(time.Second * 1):

ch <- 1


atomic.StoreUint32(_finish, 1)

case <- done:

fmt.Println("early exit")

}

}()

panic("bye") // comment this out to see normal behavior

n := <- ch

fmt.Printf("n: %v\n", n)

}

 

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

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

[go-nuts] Is this bad concurrency?

[bill . warner]

Hi,

https://play.golang.org/p/lR6_mxSjtb

I have two long running things to do, I'd like to do them in parallel, then 
sync up at the end. I've written it as a function which gets one thing 
done, and which backgrounds the second thing with a goroutine. Thing one 
has a lot of reasons to exit early, and I need to signal those to thing two 
so that the go routine can exit cleanly and not create a goroutine leak. 
Standard fare, usually solved by introducing a channel and a select 
statement. I want to signal done for early exits, including panics,  so I 
thought I would write to the done channel in a defer block. That caused a 
problem, because in the happy case, both the foreground and the background 
routines are finished, the done channel has no reader, so writing to it in 
the defer block causes "fatal error: all goroutines are asleep - deadlock!" 
So I introduced a new boolean variable ("clean_finish") that is false until 
the background job completes, and which is tested in the defer block before 
writing to the done channel. Is there anything wrong with my approach? You 
can see the code in the playground link above, or down below.


package main

import (
"sync/atomic"
"fmt"
"time"
)

func main() {
ch := make(chan int)
done := make(chan struct{})
var clean_finish uint32
defer func() { 
fin := atomic.LoadUint32(_finish)
if fin != 1 {
done <- struct{}{}
}
}()
go func() {
defer func() {
fmt.Println("we're done here")
}()
select {
case <-time.After(time.Second * 1):
ch <- 1
atomic.StoreUint32(_finish, 1)
case <- done:
fmt.Println("early exit")
}
}()
panic("bye") // comment this out to see normal behavior
n := <- ch
fmt.Printf("n: %v\n", n)
}

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

Re: [go-nuts] Re: Getting some strange benchmark results

[Agniva De Sarker]

Thanks


On Aug 18, 2017 1:42 PM,  wrote:

> From the recent GopherCon, golang's profiler has a tool for inspecting
> allocations that might solve your problem.
>
> https://youtu.be/2557w0qsDV0?list=PLq2Nv-Sh8EbZEjZdPLaQt1qh_ohZFMDj8=526
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/0vTMTgwmv4E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] multiply and divide

[Michael Jones]

Here is a minor musing from something that came up yesterday.

Sometimes we see a real number expression as simple as...

  x*y/z

...and knowing from basic algebra that...

(x*y)/z == x*(y/z)

...we might not expect much difference between the two in our code. Alas,
computer floating point does not involve real numbers, rather it uses an
approximation of them. If you will copy https://play.golang.org/p/IlDxtvx7IY
to your computer, build and run it, (too much CPU for the playground)
you'll find that the order makes a difference. Or, you can just remember
this phrase, "multiply first, then divide."

-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] Segmentation fault when linking with Go library from a C++ program

[inetic]

I think I found it, I was wrong above where I said that at first I did not 
have address
sanitizer enabled. Seems when I disable it, I no longer see any 
"Segmentation fault"
messages nor memory leak reports from the sanitizer (obviously).

That is a problem.  When you say that gdb doesn't show anything 
> useful, what do you mean?  Does it at least show where the 
> segmentation fault is occurring? 


When I run it through gdb with memory sanitizer enabled I only see the 
memory leak
reports. Never the "Segmentation fault" message.

When I don't run it through gdb, I sometimes see the memory leak report, 
but sometimes
the "Segmentation fault" message which looks like this:

# ./a.out
Options:
  --helpProduce this help message
  --repo arg (=./repo)  Path to the repository

Segmentation fault
#

Where the "Options:..." part is my output but the "Segmentation fault" line 
is not mine.

enable it, say, by executing 
>   ulimit -c unlimited 
> before starting the problem. 


Thanks for the hint, but I already had it enabled.

What C library are you using?


# ldd a.out
 linux-vdso.so.1 =>  (0x7fffdd70e000)
 libasan.so.2 => /usr/lib/x86_64-linux-gnu/libasan.so.2 (0x7f636ebfa000)
 libevent-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 (
0x7f636e9b4000)
 libevent_pthreads-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent_pthreads-
2.0.so.5 (0x7f636e7b)
 libboost_program_options.so.1.58.0 => /usr/lib/x86_64-linux-gnu/
libboost_program_options.so.1.58.0 (0x7f636e532000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (
0x7f636e1b)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f636df99000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (
0x7f636dd7c000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f636d9b2000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f636d7ad000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f636d4a4000)
 libevent_core-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5 
(0x7f636d27a000)
 /lib64/ld-linux-x86-64.so.2 (0x56445740e000)
 

> But if I'm right that this is related to exiting while the 
> runtime is being initialized, then a workaround would be to call any 
> Go function on exit, even a Go function that does nothing.


This is interesting, when I call a "go_do_nothing()" function right before 
`return 0;` from the C++ main function
, run the executable NOT through gdb, and with memory sanitizer enabled, I 
only see the "Segmentation fault"
messages. Very consistently and never any memory leak reports.

When I run it through gdb however I do sometimes see the mem leaks, never 
any crash though.

I think it looks like the sanitizer fault now. I'll try to upgrade and come 
back.

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

Re: [go-nuts] signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7fcb5ae54390

[Bhaskar Singhal]

C function just copies the parameters passed. All of the params have
escaped to heap as seen in output generated by using -gcflags "-m -m"
during build.

I am trying to figure out if there is a possibility that gc frees any of
these parameters before the C function call returns.

On Fri, Aug 18, 2017 at 7:57 PM, Ian Lance Taylor  wrote:

> On Fri, Aug 18, 2017 at 12:53 AM, Bhaskar Singhal
>  wrote:
> > I am running into a seg fault. The code keeps crashing either due to
> > unexpected signal or double free.
> >
> > Any pointers on what I am doing wrong here:
> >
> > Code Snippet:
> > // Put puts the given key / value to the kvstore
> > func (kvs *kvstore) Put(key []byte, value []byte) error {
> > /* Encode key to avoid null characters in byte[] */
> > strk := base64.StdEncoding.EncodeToString([]byte(key))
> > csk := C.CString(strk)
> > defer C.free(unsafe.Pointer(csk))
> >
> > /* Encode value to avoid null characters in byte[] */
> > strv := base64.StdEncoding.EncodeToString([]byte(value))
> > csv := C.CString(strv)
> > defer C.free(unsafe.Pointer(csv))
> >
> > if kvs.kvtree == nil {
> > return fmt.Errorf("put failed because kvtree is nil")
> > }
> > size := C.int32_t(len(strv))
> >
> > ret := C.put(kvs.kvtree, csk, csv, )
> > if ret != C.int8_t(1) {
> > return fmt.Errorf("kvtree put failed %g", ret)
> > }
> > return nil
> > }
> >
> > C Function Put:
> > int8_t put(KVTree* kv,
> >   const char* key,
> >   const char* value,
> >   const int32_t* valuebytes);
>
>
> It really depends on how the C function behaves.  My guess is that it
> does not expect the values to be freed.
>
> Ian
>

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

[go-nuts] nginx and upstream prematurely closed connection while reading upstream

[wilk]

Hi,

I'm experiencing a lot of log in nginx :
upstream prematurely closed connection while reading upstream

Looking in my code it's because I added 

w.Header().Set("content-length", strconv.Itoa(len(w.Body.Bytes(
If i remove it, no more logs and my clients are happy again

I use an httptest.ResponseRecorder as a response buffer.

then write the headers (content type and cookies), write the code and 
write the body wrt.Write(w.Body.Bytes()). Nothing special, if i look 
with curl the content-lenght seems to be ok.

I don't see where i did a mistake, and it's difficult to find because 
i cannot reproduce it localy.

Thanks

-- 
William

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

Re: [go-nuts] signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7fcb5ae54390

[Ian Lance Taylor]

On Fri, Aug 18, 2017 at 12:53 AM, Bhaskar Singhal
 wrote:
> I am running into a seg fault. The code keeps crashing either due to
> unexpected signal or double free.
>
> Any pointers on what I am doing wrong here:
>
> Code Snippet:
> // Put puts the given key / value to the kvstore
> func (kvs *kvstore) Put(key []byte, value []byte) error {
> /* Encode key to avoid null characters in byte[] */
> strk := base64.StdEncoding.EncodeToString([]byte(key))
> csk := C.CString(strk)
> defer C.free(unsafe.Pointer(csk))
>
> /* Encode value to avoid null characters in byte[] */
> strv := base64.StdEncoding.EncodeToString([]byte(value))
> csv := C.CString(strv)
> defer C.free(unsafe.Pointer(csv))
>
> if kvs.kvtree == nil {
> return fmt.Errorf("put failed because kvtree is nil")
> }
> size := C.int32_t(len(strv))
>
> ret := C.put(kvs.kvtree, csk, csv, )
> if ret != C.int8_t(1) {
> return fmt.Errorf("kvtree put failed %g", ret)
> }
> return nil
> }
>
> C Function Put:
> int8_t put(KVTree* kv,
>   const char* key,
>   const char* value,
>   const int32_t* valuebytes);


It really depends on how the C function behaves.  My guess is that it
does not expect the values to be freed.

Ian

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

Re: [go-nuts] Go channels overused and hyped?

[Michael Jones]

yes... everything is good for what it is designed for and less-good for
what it is not designed for.

mutex-protected counters are good
channels for data communication are good

neither is a perfect stand in for the other. nothin wrong with channels.

On Fri, Aug 18, 2017 at 4:38 AM, Tamás Gulácsi  wrote:

> No. Use channels to coordinate and send data between goroutines, and other
> sync primitives to coordinate access to shared resources. Both has its pros
> and cons, use the best tool for the job.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] Segmentation fault when linking with Go library from a C++ program

[Konstantin Khomoutov]

On Fri, Aug 18, 2017 at 04:21:27AM -0700, ine...@gmail.com wrote:
> I have a C++ application from which I need to call Go functions. I noticed 
> that the application crashes
> on exit from the `main` function (with only a "Segmentation fault" message, 
> no core dump

Not to answer your question, but these days core dumping is usually
disabled by default through the "soft" limit, but it's possible to
enable it, say, by executing

  ulimit -c unlimited

before starting the problem.

[...]

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

Re: [go-nuts] Segmentation fault when linking with Go library from a C++ program

[Ian Lance Taylor]

On Fri, Aug 18, 2017 at 4:21 AM,   wrote:
>
> I have a C++ application from which I need to call Go functions. I noticed
> that the application crashes
> on exit from the `main` function (with only a "Segmentation fault" message,
> no core dump and neither
> did gdb show anything useful) about once in three runs.

That is a problem.  When you say that gdb doesn't show anything
useful, what do you mean?  Does it at least show where the
segmentation fault is occurring?


> Then I added the
> `-fsanitize=address` flag to
> the build and started to see messages such as these:

These are not problems.  These just  mean that some of Go's internal
libraries are not using the address sanitizer hooks.  The memory will
be freed, and even it weren't, a few small space leaks could not cause
a segmentation violation.


> I reduced the code which can reproduce these to the three attached files. 
> With this reduced code I can see the failures
> a lot less often though. Sometimes I can see the error quite quickly, but 
> sometimes I need to let the `run.sh` script run
> for more than a minute.

Thanks for the test case.  Unfortunately, I was unable to recreate the problem.

Looking at the code, it looks like the problem may be related to
exiting the program while the Go runtime is still being initialized.
I can't think of any reason why that would be a problem, but I also
can't think of anything else.  What C library are you using?  What
version?


> Do I need to call some cgo function to properly de-initialize go when exiting 
> the main function?

No.  But if I'm right that this is related to exiting while the
runtime is being initialized, then a workaround would be to call any
Go function on exit, even a Go function that does nothing.  Calling a
Go function will automatically wait until runtime initialization is
complete.


Ian

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

[go-nuts] Segmentation fault when linking with Go library from a C++ program

[inetic]

I have a C++ application from which I need to call Go functions. I noticed 
that the application crashes
on exit from the `main` function (with only a "Segmentation fault" message, 
no core dump and neither
did gdb show anything useful) about once in three runs. Then I added the 
`-fsanitize=address` flag to
the build and started to see messages such as these:

=
==8006==ERROR: LeakSanitizer: detected memory leaks


Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f9ef4571602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x40421d in x_cgo_thread_start 
/usr/local/go/src/runtime/cgo/gcc_util.c:15
#2 0x42bcff in runtime.startm /usr/local/go/src/runtime/proc.go:1698
#3 0x42c059 in runtime.wakep /usr/local/go/src/runtime/proc.go:1779
#4 0x42f179 in runtime.newproc1 /usr/local/go/src/runtime/proc.go:2958
#5 0x4490d2 in runtime.newproc.func1 
/usr/local/go/src/runtime/proc.go:2845
#6 0x4498d1 in runtime.systemstack 
/usr/local/go/src/runtime/asm_amd64.s:327


Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f9ef4571602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x40421d in x_cgo_thread_start 
/usr/local/go/src/runtime/cgo/gcc_util.c:15
#2 0x4488a7 in runtime.main.func1 /usr/local/go/src/runtime/proc.go:126
#3 0x4498d1 in runtime.systemstack 
/usr/local/go/src/runtime/asm_amd64.s:327


Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f9ef4571602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x40421d in x_cgo_thread_start 
/usr/local/go/src/runtime/cgo/gcc_util.c:15
#2 0x42bcff in runtime.startm /usr/local/go/src/runtime/proc.go:1698
#3 0x42bdd6 in runtime.handoffp /usr/local/go/src/runtime/proc.go:1725
#4 0x42c1f4 in runtime.stoplockedm 
/usr/local/go/src/runtime/proc.go:1793
#5 0x42d5da in runtime.schedule /usr/local/go/src/runtime/proc.go:2180
#6 0x42d730 in runtime.park_m /usr/local/go/src/runtime/proc.go:2285
#7 0x449842 in runtime.mcall /usr/local/go/src/runtime/asm_amd64.s:269


SUMMARY: AddressSanitizer: 72 byte(s) leaked in 3 allocation(s).

or

=
==28395==ERROR: LeakSanitizer: detected memory leaks


Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f562b171602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x403a0d in x_cgo_thread_start 
/usr/local/go/src/runtime/cgo/gcc_util.c:15
#2 0x42b4ef in runtime.startm /usr/local/go/src/runtime/proc.go:1698
#3 0x42b5c6 in runtime.handoffp /usr/local/go/src/runtime/proc.go:1725
#4 0x42b9e4 in runtime.stoplockedm 
/usr/local/go/src/runtime/proc.go:1793
#5 0x42cdca in runtime.schedule /usr/local/go/src/runtime/proc.go:2180
#6 0x42cf20 in runtime.park_m /usr/local/go/src/runtime/proc.go:2285
#7 0x449032 in runtime.mcall /usr/local/go/src/runtime/asm_amd64.s:269


Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f562b171602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x403a0d in x_cgo_thread_start 
/usr/local/go/src/runtime/cgo/gcc_util.c:15
#2 0x42b4ef in runtime.startm /usr/local/go/src/runtime/proc.go:1698
#3 0x42b849 in runtime.wakep /usr/local/go/src/runtime/proc.go:1779
#4 0x42c8b4 in runtime.resetspinning 
/usr/local/go/src/runtime/proc.go:2141
#5 0x42cc09 in runtime.schedule /usr/local/go/src/runtime/proc.go:2229
#6 0x42a2db in runtime.mstart1 /usr/local/go/src/runtime/proc.go:1189
#7 0x42a1f5 in runtime.mstart /usr/local/go/src/runtime/proc.go:1149
#8 0x403a62  (/home/peter/work/tmp/minimal-cgo/a.out+0x403a62)


SUMMARY: AddressSanitizer: 48 byte(s) leaked in 2 allocation(s).

but most often just this one:

=
==17138==ERROR: LeakSanitizer: detected memory leaks


Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f15bfe0e602 in malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x403eed in x_cgo_thread_start 
/usr/local/go/src/runtime/cgo/gcc_util.c:15
#2 0x448577 in runtime.main.func1 /usr/local/go/src/runtime/proc.go:126
#3 0x4495a1 in runtime.systemstack 
/usr/local/go/src/runtime/asm_amd64.s:327


SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).

I reduced the code which can reproduce these to the three attached files. 
With this reduced code I can see the failures
a lot less often though. Sometimes I can see the error quite quickly, but 
sometimes I need to let the `run.sh` script run
for more than a minute.

I have tested with go1.8, go1.8.3 and go1.9rc2 (linux amd64) with the same 
results.

~ > g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

Do I need to call some cgo function to properly de-initialize go when 
exiting the main function?

Regards,

Peter


-- 
You received this message because 

[go-nuts] Re: FAIL: TestBuildmodePIE

[Marvin Stenger]

This is https://github.com/golang/go/issues/21452

Am Freitag, 18. August 2017 13:31:16 UTC+2 schrieb SauliusGurklys:
>
> Hi,
>
> I'm using 
>
> $ uname -a
> Linux alio 4.11.12-1-MANJARO #1 SMP PREEMPT Fri Jul 21 08:51:46 UTC 2017 
> x86_64 GNU/Linux
>
> For a couple of days my go build from source started to fail on test 
> "TestBuildmodePIE"
>
> ...
> ok  cmd/doc 0.027s
> ok  cmd/fix 0.045s
> --- FAIL: TestBuildmodePIE (1.27s)
> go_test.go:312: running testgo [build -buildmode=pie -o 
> /tmp/gotest428943951/main /tmp/gotest428943951/main.go]
> go_test.go:325: standard error:
> go_test.go:326: # command-line-arguments
> 
> /usr/local/src/sagu/go-all/go/pkg/linux_amd64_shared/runtime/cgo.a(_go_.o): 
> object is [linux amd64 devel +98276d6abe Mon Aug 14 04:45:52 2017 + 
> X:framepointer] expected [linux amd64 devel +66a1
> d37bf7 Fri Aug 18 09:28:16 2017 + ]
> 
> /usr/local/src/sagu/go-all/go/pkg/linux_amd64_shared/runtime/cgo.a(asm_amd64.o):
>  
> object is [linux amd64 devel +98276d6abe Mon Aug 14 04:45:52 2017 +] 
> expected [linux amd64 devel +66a1d37bf7 Fri
>  Aug 18 09:28:16 2017 + ]
>
> go_test.go:335: go [build -buildmode=pie -o 
> /tmp/gotest428943951/main /tmp/gotest428943951/main.go] failed 
> unexpectedly: exit status 2
> FAIL
> FAILcmd/go  50.024s
> ok  cmd/go/internal/generate0.024s
> ...
>
> I did a small investigation and it seems that failures began after
>
> commit b7c600d6ba8828dbdc6a047aac240d40b4fc44a7 (HEAD)
> Author: Hiroshi Ioka 
> Date:   Sat Aug 5 18:25:26 2017 +0900
>
> cmd/go, cmd/link: enable buildmode=pie on darwin/amd64
> 
> Change some configurations to enable the feature. Also add the test.
> This CL doesn't include internal linking support which is tentatively
> disabled due to #18968. We could do that another day.
> 
> Fixes #21220
> 
> Change-Id: I601d2d78446d36332acc70be0d5b9461ac635208
> Reviewed-on: https://go-review.googlesource.com/54790
> Reviewed-by: Ian Lance Taylor 
> Run-TryBot: Ian Lance Taylor 
> TryBot-Result: Gobot Gobot 
>
> Has anyboy an idea how to fix this? 
>
> Thanks,
> --
> Saulius
>

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

Re: [go-nuts] Go channels overused and hyped?

[Tamás Gulácsi]

No. Use channels to coordinate and send data between goroutines, and other sync 
primitives to coordinate access to shared resources. Both has its pros and 
cons, use the best tool for the job.

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

[go-nuts] FAIL: TestBuildmodePIE

[SauliusGurklys]

Hi,

I'm using 

$ uname -a
Linux alio 4.11.12-1-MANJARO #1 SMP PREEMPT Fri Jul 21 08:51:46 UTC 2017 
x86_64 GNU/Linux

For a couple of days my go build from source started to fail on test 
"TestBuildmodePIE"

...
ok  cmd/doc 0.027s
ok  cmd/fix 0.045s
--- FAIL: TestBuildmodePIE (1.27s)
go_test.go:312: running testgo [build -buildmode=pie -o 
/tmp/gotest428943951/main /tmp/gotest428943951/main.go]
go_test.go:325: standard error:
go_test.go:326: # command-line-arguments

/usr/local/src/sagu/go-all/go/pkg/linux_amd64_shared/runtime/cgo.a(_go_.o): 
object is [linux amd64 devel +98276d6abe Mon Aug 14 04:45:52 2017 + 
X:framepointer] expected [linux amd64 devel +66a1
d37bf7 Fri Aug 18 09:28:16 2017 + ]

/usr/local/src/sagu/go-all/go/pkg/linux_amd64_shared/runtime/cgo.a(asm_amd64.o):
 
object is [linux amd64 devel +98276d6abe Mon Aug 14 04:45:52 2017 +] 
expected [linux amd64 devel +66a1d37bf7 Fri
 Aug 18 09:28:16 2017 + ]

go_test.go:335: go [build -buildmode=pie -o 
/tmp/gotest428943951/main /tmp/gotest428943951/main.go] failed 
unexpectedly: exit status 2
FAIL
FAILcmd/go  50.024s
ok  cmd/go/internal/generate0.024s
...

I did a small investigation and it seems that failures began after

commit b7c600d6ba8828dbdc6a047aac240d40b4fc44a7 (HEAD)
Author: Hiroshi Ioka 
Date:   Sat Aug 5 18:25:26 2017 +0900

cmd/go, cmd/link: enable buildmode=pie on darwin/amd64

Change some configurations to enable the feature. Also add the test.
This CL doesn't include internal linking support which is tentatively
disabled due to #18968. We could do that another day.

Fixes #21220

Change-Id: I601d2d78446d36332acc70be0d5b9461ac635208
Reviewed-on: https://go-review.googlesource.com/54790
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 

Has anyboy an idea how to fix this? 

Thanks,
--
Saulius

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

Re: [go-nuts] Domain-driven design and go

[juicemia]

You're right. A lot of it is stuff you pick up as you grow your skills. I 
wrote the article to show how the Go community has standardized on patterns 
that were talked about in the book. I guess I could have done a better job 
of accentuating that.

I think a great example of that is the repository pattern. When I read the 
section on repositories I had already seen it in other Go applications I've 
worked on.

I'll be writing a follow up soon, i'll make sure to make that point more 
clear.

The thing about aggregates is that it isn't just about structuring data. 
It's about how you interact with the data.

A car "containing" its wheels falls short of explaining what an aggregate 
is.

The important thing about the aggregate is how its members are accessed, 
which is through the root object.

Also, there's a lot more to the book than just those three patterns. The 
first section of the book is entirely non-technical, and I think it's where 
most of the value in that book lies.

Thanks for the feedback.

On Friday, August 18, 2017 at 6:47:22 AM UTC-4, Konstantin Khomoutov wrote:
>
> On Fri, Aug 18, 2017 at 03:29:01AM -0700, Hugo Torres wrote: 
>
> > Recently I've been reading "Domain Driven Design" and I think it has 
> some 
> > useful stuff about organizing Go programs. 
> > 
> > I wrote some of my thoughts up on my blog here 
> > . 
> > 
> > Would love to know what everybody thinks. 
>
> I'm not sure I got the point from reading. 
>
> What you have labelled as "Aggregates" is just a conventional 
> common-sense approach to structuring data: of course, a car "contains" 
> (hence "aggregates") its wheels. 
>
> What was labelled "Factories" are the standard ways to produce values of 
> types which do not have useful zero-values or just are convenient for 
> one reason or another.  Examples of what you call "factories" are right 
> there in the go-to documents for Go beginners [1, 2]. 
>
> What was labelled "Repositories" is a pretty standard way of decoupling 
> disparate parts of code by using an interface.  Interfaces naturally 
> decouple the code which only relies on some behaviour from the code 
> which defines types implementing that behaviour. 
>
> I'm afraid you might be too dragged away by that shallow-water 
> theoretisation which appear to be done by this book. 
> As someone commented on Amazon, «Another meta-methodology book filled 
> with self-evident observations normally learned on the job. A lot of it 
> is just common sense.» — based on your blog post, it sounds just about 
> correct, sorry. 
>
> 1. https://blog.golang.org/package-names 
> 2. https://golang.org/doc/effective_go.html 
>

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

Re: [go-nuts] Domain-driven design and go

[Konstantin Khomoutov]

On Fri, Aug 18, 2017 at 03:29:01AM -0700, Hugo Torres wrote:

> Recently I've been reading "Domain Driven Design" and I think it has some 
> useful stuff about organizing Go programs.
> 
> I wrote some of my thoughts up on my blog here 
> .
> 
> Would love to know what everybody thinks.

I'm not sure I got the point from reading.

What you have labelled as "Aggregates" is just a conventional
common-sense approach to structuring data: of course, a car "contains"
(hence "aggregates") its wheels.

What was labelled "Factories" are the standard ways to produce values of
types which do not have useful zero-values or just are convenient for
one reason or another.  Examples of what you call "factories" are right
there in the go-to documents for Go beginners [1, 2].

What was labelled "Repositories" is a pretty standard way of decoupling
disparate parts of code by using an interface.  Interfaces naturally
decouple the code which only relies on some behaviour from the code
which defines types implementing that behaviour.

I'm afraid you might be too dragged away by that shallow-water
theoretisation which appear to be done by this book.
As someone commented on Amazon, «Another meta-methodology book filled
with self-evident observations normally learned on the job. A lot of it
is just common sense.» — based on your blog post, it sounds just about
correct, sorry.

1. https://blog.golang.org/package-names
2. https://golang.org/doc/effective_go.html

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

[go-nuts] Re: [ANN] Gop - Build and manage your Go applications out of GOPATH

[Fino]

Hello,

Can I ask for a typical use case? 

BR fino

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

Re: [go-nuts] How do you debug Go itself on VM env or Docker container?

[Konstantin Khomoutov]

On Fri, Aug 18, 2017 at 12:26:02AM -0700, 高橋誠二 wrote:

> I'm trying to debug and run `./all.bash` with VM or docker, but they don't 
> work for several reasons.
> 
> On VM, I added box of CentOS and Ubuntu, though, they cancels ./all.bash at 
> `hardlink` testing.

The "VM" is too vague a term which these days may mean a whole lot of
very different things.

I'm pretty confident that if we define "a VM" to mean a fully
virtualized machine running on any popular host such as KVM or
VirtualBox, hardlinks must work there just OK -- of course, provided
you've installed the guest OS on a POSIX-compliant FS (such as ext4 for
the case of CentOS/Ubuntu).

I'm also pretty confident such stuff should work just OK in an LXC
container -- again provided the host os (this time) uses a
POSIX-compatible FS which is the case most of the time.

In any case, the exact error message (with some textual context around
it) could help us try to light more shed on the source of the problem.

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

[go-nuts] Domain-driven design and go

[Hugo Torres]

Hi everybody,

Recently I've been reading "Domain Driven Design" and I think it has some 
useful stuff about organizing Go programs.

I wrote some of my thoughts up on my blog here 
.

Would love to know what everybody thinks.

Thanks,

Hugo

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

[go-nuts] Re: How do you debug Go itself on VM env or Docker container?

[高橋誠二]

Do you know any setting file like Vagrantfile or Dockerfile, which is 
appropriate for this case?

2017年8月18日金曜日 17時50分30秒 UTC+9 Tamás Gulácsi:
>
> Fix your VM?

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

[go-nuts] How do you debug Go itself on VM env or Docker container?

[Tamás Gulácsi]

Fix your VM?

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

Re: [go-nuts] Go channels overused and hyped?

[snmed]

Hi Michael

Thank you very much for your very informative and elaborating post. I never 
had seen that blog this way, but your post has opened my eyes and now is 
clear that one should not compare apples with pears.
So the tradeoff is, use concurrency in a safe manner or squezze the last 
drop performance out of the application, but be aware of shooting in your 
own leg. So the conclusion is, use channels to get the job done and
if in real use any performance problem pops up, analyze it and verify if 
the bottleneck is really caused by channels and if it's not a fault in the 
architecture , right?

Cheers snmed


Am Samstag, 12. August 2017 23:37:45 UTC+2 schrieb Michael Jones:
>
> snmed, 
>
> My disappointment with that blog post is that it does not address the 
> larger issue, which some people here have clarified, but to be clear on the 
> larger issue and the various points raised about channels:
>
> SMALL BENCHMARKS ARE HARD
>
> Benchmarking is harder than it seems, because computers since the IBM 
> 360/85 (1969), the DEC PDP-11/70 (1975), and a others before have memory 
> caches. They can also have multiple CPUs, multiple levels of memory cache, 
> and since 1964's CDC 6000, multiple threads active in a single CPU (the 
> basis of the first NVIDIA GeForce GPU and rediscovered by intel as Jackson 
> Technology, aka SMT, a few years later).
>
> In a world where computers read, write, and compute multiple things at 
> once, it is quite difficult to measure the cost of any single thing. Why? 
> Because if that one thing can be done in some idle part of the computer 
> while other things are happening, then the effective cost is zero. 
>
> Even if you manage to measure that one thing somehow with sufficient 
> scaffolding and after disabling your modern CPU's power saving speed 
> degrader and myriad other processes and performance modulators such as 
> inside the CPU uOp dispatch priority and the like, the problem is, how to 
> understand it and extrapolate from it.
>
> To be clear, if it takes a perfectly measured average of 140 ns +/- 11ns 
> to do something, and you do 100 of them, it will likely not add 100x that 
> time or 100x that variance to your application's actual performance rates. 
> Maybe all 100 of those fit in "empty spots" so the cost is zero. Maybe they 
> conflict with instruction scheduling, bus activity, or cache/VM activity in 
> such a way that they add 10x that time. 
>
> This is why microbenchmarks are so hard to understand. They are hard to 
> write properly, they are hard to measure in a meaningful way, and they are 
> hard to extrapolate with confidence. (You should do them, but, you should 
> always keep in mind that the application-level, real-world impact may be 0x 
> or 100x that much cost.)
>
> CONCURRENT PROGRAMMING IS HARD
>
> Doing things concurrently generally implies one or more spreading steps 
> where the code widens one thing to multiple things, and one or more 
> gathering steps where the multiple things narrow to fewer things, 
> ultimately to one thing, like knowing when to exit the program. For decades 
> there have been frequent errors in widening, narrowing, and data and device 
> conflicts in the concurrent phase. Code that works for years may suddenly 
> break. Code that looks simple my never work. Natural intuition in such 
> cases often leads one astray.
>
> One solution is to be afraid of concurrency and avoid it. One is to 
> embrace it, but with special armor as if handling hot lava or a pit of 
> vipers. A middle route is to only allow it in such a way that it its tame 
> (Lava in insulated containers, snakes asleep in darkened boxes.) One such 
> mild route--Communicating Sequential Processes--was pioneered by C. A. R. 
> Hoare, the inventor of Quicksort. Per Brinch Hansen has an excellent book 
> about OS construction via the method, and Go is one of CSP's direct 
> decedents. Go's channels, along with select, receive, send, and close 
> operations, are its presence. 
>
> SMALL BENCHMARKS OF CONCURRENCY PRIMITIVES IS VERY HARD
>
> It is hard to measure directly in much the same way it is hard to directly 
> measure curved space-time. Indirect ways are hard too. As above, even when 
> you can measure them, it is hard to understand what that data says in the 
> context of your program or any program other than the test harness. 
>
> This is where that blog post comes in. To paraphrase, "I think some of 
> Go's mild, safe mechanisms lack a feature that I wish for, and not only 
> that, when I use them to emulate some parts of my low-level lava-juggling 
> armor, they are not as fast. Oh no! Yet, I still love Go." Well people see 
> that, seem to miss:
>
> a. Why in the heck would you use high-level magic to emulate low-level 
> tools? In the case of channels, they already use lava juggling and snake 
> charming tools hidden safely inside their implementation.
>
> b. How can you compare performance of high level program structuring 
> elements 

Re: [go-nuts] The memory release about Turning C arrays into Go slices

[Konstantin Khomoutov]

On Fri, Aug 18, 2017 at 10:39:29AM +0300, Konstantin Khomoutov wrote:

[...]
> There can't be easy answer to a question like this in C.
> Consider:
> 
>   // This function clearly transfers the ownership of the memory
>   // it returns to the caller.
>   int* allocate(int n)
>   {
> int *mem = (int*)malloc(n * sizeof(int));
> if (mem == NULL) {
>   panic("Out of memory");
> }
>   }

Sorry, I've missed the crucial return statement; the code should have
instead been:

   // This function clearly transfers the ownership of the memory
   // it returns to the caller.
   int* allocate(int n)
   {
 int *mem = (int*)malloc(n * sizeof(int));
 if (mem == NULL) {
   panic("Out of memory");
 }
 return mem;
   }

[...]

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

[go-nuts] Re: Getting some strange benchmark results

[kpratt]

>From the recent GopherCon, golang's profiler has a tool for inspecting 
allocations that might solve your problem.

https://youtu.be/2557w0qsDV0?list=PLq2Nv-Sh8EbZEjZdPLaQt1qh_ohZFMDj8=526

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

[go-nuts] Compile-time Instrumentation

[kpratt]

Is there any way in go to do this?

Ideally I'd like to be able to do something like pass the compiler an AST 
-> AST function to be run between front and back end compile steps. The 
best way I see atm is to do a precompile job that dumps the AST back out to 
a different directory and compiles that.
I've heard it suggested that the race detector does something like this and 
that it's possible that api could be exposed in the future.

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

[go-nuts] signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x7fcb5ae54390

[Bhaskar Singhal]

I am running into a seg fault. The code keeps crashing either due to 
unexpected signal or double free.

Any pointers on what I am doing wrong here:

Code Snippet:
// Put puts the given key / value to the kvstore
func (kvs *kvstore) Put(key []byte, value []byte) error {
/* Encode key to avoid null characters in byte[] */
strk := base64.StdEncoding.EncodeToString([]byte(key))
csk := C.CString(strk)
defer C.free(unsafe.Pointer(csk))

/* Encode value to avoid null characters in byte[] */
strv := base64.StdEncoding.EncodeToString([]byte(value))
csv := C.CString(strv)
defer C.free(unsafe.Pointer(csv))

if kvs.kvtree == nil {
return fmt.Errorf("put failed because kvtree is nil")
}
size := C.int32_t(len(strv))

ret := C.put(kvs.kvtree, csk, csv, )
if ret != C.int8_t(1) {
return fmt.Errorf("kvtree put failed %g", ret)
}
return nil
}

C Function Put: 
int8_t put(KVTree* kv,  
  const char* key,
  const char* value, 
  const int32_t* valuebytes);   


Stack Trace:
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 
pc=0x7fcb5ae54390]

runtime stack:
runtime.throw(0xeffa94, 0x2a)
/usr/lib/go-1.8/src/runtime/panic.go:596 +0x95
runtime.sigpanic()
/usr/lib/go-1.8/src/runtime/signal_unix.go:274 +0x2db

goroutine 1117 [syscall, locked to thread]:
runtime.cgocall(0xc88080, 0xc4204d7a70, 0xc4204d7a98)
/usr/lib/go-1.8/src/runtime/cgocall.go:131 +0xe2 fp=0xc4204d7a40 
sp=0xc4204d7a00
github.com/app/go-app/tempdb._Cfunc_put(0x34ebfd0, 0x7fcb4c027550, 
0x7fcb4c008b10, 0x7fcb4c00cf90, 0x0)
github.com/app/go-app/tempdb/_obj/_cgo_gotypes.go:131 +0x4a 
fp=0xc4204d7a70 sp=0xc4204d7a40
github.com/app/go-app/tempdb.(*kvstore).Put.func4(0x34ebfd0, 
0x7fcb4c027550, 0x7fcb4c008b10, 0x7fcb4c00cf90, 0xc42192a1ec)

/root/go-app/build/_workspace/src/github.com/app/go-app/tempdb/database.go:164 
+0x82 fp=0xc4204d7aa8 sp=0xc4204d7a70
github.com/app/go-app/tempdb.(*kvstore).Put(0xc420246c60, 0xc4218bc8a0, 
0x29, 0x30, 0xc42192a1e4, 0x1, 0x1, 0x0, 0x0)

/root/go-app/build/_workspace/src/github.com/app/go-app/tempdb/database.go:164 
+0x1d3 fp=0xc4204d7b40 sp=0xc4204d7aa8
github.com/app/go-app/core.WriteBlockReceipts(0x16dd480, 0xc420246c60, 
0xffcd5c15251c6f60, 0x36efda5ab3f463e3, 0x2f747de9501058d8, 
0x1000f51c73e6dc25, 0xe8, 0x0, 0x0, 0x0, ...)

/root/go-app/build/_workspace/src/github.com/app/go-app/core/database_util.go:428
 
+0x2f3 fp=0xc4204d7c88 sp=0xc4204d7b40
github.com/app/go-app/core.(*BC).InsertRC.func1(0x1)

/root/go-app/build/_workspace/src/github.com/app/go-app/core/bc.go:750 
+0x4d3 fp=0xc4204d7fa0 sp=0xc4204d7c88
github.com/app/go-app/core.(*BC).InsertRC.func2(0xc421825670, 0xc420d0fce0, 
0x1)

/root/go-app/build/_workspace/src/github.com/app/go-app/core/bc.go:777 
+0x56 fp=0xc4204d7fc8 sp=0xc4204d7fa0
runtime.goexit()
/usr/lib/go-1.8/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc4204d7fd0 
sp=0xc4204d7fc8
created by github.com/app/go-app/core.(*BC).InsertRC

/root/go-app/build/_workspace/src/github.com/app/go-app/core/bc.go:778 
+0x5da



Thanks,
Bhaskar

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

Re: [go-nuts] The memory release about Turning C arrays into Go slices

[Konstantin Khomoutov]

On Thu, Aug 17, 2017 at 06:50:42PM -0700, jianzhang...@gmail.com wrote:

> > > As the instruction 
> > > of https://github.com/golang/go/wiki/cgo#turning-c-arrays-into-go-slices 
> > > shows, the GC of Go will not release it. 
> > > An example as the following, but I have a question about when and how to 
> > > release this `slice`? 
> >
> > You shouldn't: the GC won't touch the memory it does not "own" so it 
> > will eventually collect the slice structure itself but won't do anything 
> > to its underlying array (which value you obtained via that double 
> > type-conversion). 
> >
> > You should supposedly be instead concerned with freeing the array's 
> > memory (via calling C.free or some dedicated function to do this 
> > provided by your C side, if any).  As always with C, you should only do 
> > that if that getTheArray() function's semantics are such that its caller 
> > "owns" the memory the function returns. 
[...]
> Thanks your reply, you mean I should be release the memory of `theCArray` 
> in C side?
> I still have some doubts, and I made a clearer example as the below, any 
> problem with it?

I see no reason to defer calls to C.free().
defer is a costly operation, and it should be only used if the resource
the deferred call is intended to free can be used in arbitrary places
down the code paths after it's allocated; that's not the case there.

> So, the memory of this tmpslice should be release by release the argv on C 
> side?

Yes and no.

Yes, if that memory was produced by a function whose semantics are
"the caller is responsible to freeing the memory of the data I
returned", and no otherwise.

There can't be easy answer to a question like this in C.
Consider:

  // This function clearly transfers the ownership of the memory
  // it returns to the caller.
  int* allocate(int n)
  {
int *mem = (int*)malloc(n * sizeof(int));
if (mem == NULL) {
  panic("Out of memory");
}
  }

  // But this one doesn't.
  int* find_first_non_zero(int *p, int count)
  {
for (i = 0; i < count; i++) {
  if p[i] > 0 {
return [i];
  }
}
return NULL;
  }

I tried to highlight that even though the latter function returns a
pointer to memory, its caller is not supposed to do anything with that
pointer (other than supposedly checking it for being non-NULL and
dereferencing otherwise).

You should apply the same logic to the code on your C side: if the
function which is used to obtain the value for the "argv" argument
of GoStrings() actually allocates the memory and supposes its caller has
to deallocate it theirselves, go on and free it.  Otherwise don't.

> func GoStrings(length int, argv **C.char) []string {
> 
> tmpslice := (*[1 << 30]*C.char)(unsafe.Pointer(argv))[:length:length
> ]
> gostrings := make([]string, length)
> for i, s := range tmpslice {
> gostrings[i] = C.GoString(s)
> defer C.free(unsafe.Pointer(s))
> }
> return gostrings
> }
> 

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

Re: [go-nuts] Calling Julia from Go

[Konstantin Khomoutov]

On Wed, Aug 16, 2017 at 11:57:51PM -0700, mrech...@gmail.com wrote:

> I would like to implement a valuation server. For the whole server 
> infrastructure I would like to use Go, because it feels more natural than 
> any other language for it. For the implementation of the valuations I would 
> like to use Julia. Thus, using the aforementioned languages where (IMHO) 
> their strengths are. Googling turned up nothing so far except for an old 
> post on this list suggesting that it is indeed not too easy: 
> https://groups.google.com/d/msg/golang-nuts/Tl7IMu6UnZ4/PBqA_v4rZhEJ
> Is anyone aware of an existing solution for embedding Julia into Go?

I'm not familiar with Julia, but I'd offer two possible points to
consider:

* If Julia code can be compiled to a library exposing C interface
  (as Go makes possible on some platforms with the compiler's option
  -buildmode=c-archive), you can do just that and the call it from Go
  via the standard Go's cgo facility.

* You may consider an often overlooked approach to just not embed
  anything to anything else and instead employ IPC (inter-process
  communication).

  Say, you could possibly compile your Julia program
  so that it reads data in certain agreed-upon format on its stdin
  and writes the results of processing them to its stdout.

  Your Go server then merely starts your Julia program and wires two
  pipes to those standard I/O streams of the process it created.
  Communication then becomes a matter of writing stuff to one of those
  pipes and then reading the result from another one.

  If your Julia server need to be multithreaded, it's possible to
  use "job identifiers" with each task submitted to that Julia process;
  this would allow the latter to perform the jobs in parallel and
  use those job IDs in its answers which then could come out the result
  pipe in any order.

Certainly the latter approach is slower than the first but it's
definitely easier to implement and to reason about, and it fully
decouples both programs.

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

[go-nuts] How do you debug Go itself on VM env or Docker container?

[高橋誠二]

I'm trying to debug and run `./all.bash` with VM or docker, but they don't 
work for several reasons.

On VM, I added box of CentOS and Ubuntu, though, they cancels ./all.bash at 
`hardlink` testing.
And on docker, it also fails cuz of the permission of host directory, which 
includes `src`, so they can't create temporary directories for testing.

How do you debug them without soiling your host environment?

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