I was wrong about the gc not getting memory back from the goroutines. I
think it does get that through the gcResetMarkState function.
So I don't think the # of goroutines are the issue..I'm sorry if I
misled you
On Tuesday, 30 April 2019 00:28:29 UTC-7, vaastav anand wrot
oved from allgs.
On Monday, 29 April 2019 23:54:54 UTC-7, Justin Israel wrote:
>
>
>
> On Tue, Apr 30, 2019 at 6:33 PM vaastav anand > wrote:
>
>> I have encountered a SIGBUS with go before but I was hacking inside the
>> runtime and using shared mem with mmap.
>&g
cause a SIGBUS.
On Monday, 29 April 2019 23:25:52 UTC-7, Justin Israel wrote:
>
>
>
> On Tue, Apr 30, 2019 at 6:09 PM vaastav anand > wrote:
>
>> Ok, so in the 2nd piece of code you posted, is some request being pushed
>> onto some OS queue? If so, is it possible th
without
really knowing what the application might really be doing.
On Monday, 29 April 2019 22:57:40 UTC-7, Justin Israel wrote:
>
>
>
> On Tue, Apr 30, 2019 at 5:43 PM vaastav anand > wrote:
>
>> I'd be very surprised if the anonymous goroutine is the reason behind a
>
I'd be very surprised if the anonymous goroutine is the reason behind a
SIGBUS violation.
So, if I remember SIGBUS correctly, it means that you are issuing a
read/write to a memory address which is not really addressable or it is
misaligned. I think the chances of the address being misaligned ar
It could be due to some anti-virus scanner deleting files.
Here is the relevant issue : https://github.com/golang/go/issues/26195
On Monday, 29 April 2019 22:02:33 UTC-7, Avetis Sargsian wrote:
>
> I set GOTMPDIR to E:\temp folder
>>
> and here is the result
>
> PS F:\GoWorckspace\src\hello> go i
The issue is that you have multiple package names in the same folder. In
this specific case it is easygen and easygen_test.
You should have 1 package per folder.
The reason your test files did not raise this issue is because _test.go
files are automatically excluded when packages are being compil
You could put such packages at $GOPATH/src/local/name_of_package.
This means that if I have a project that was using the specific project,
the import would be as follows
*import "local/name_of_package" *
Although, if the package is available online (such as github), it is better
to "install" s
Ahh that makes sense thank you.
I think this file in Delve :
https://github.com/go-delve/delve/blob/master/pkg/proc/bininfo.go does
exactly what I need if I am not wrong.
On Wednesday, 10 April 2019 21:04:49 UTC-7, Ian Lance Taylor wrote:
>
> On Wed, Apr 10, 2019 at 5:27 PM vaastav
d thus must have debugging info associated with it.)
PS Thanks so much for all the help! I really do appreciate it.
On Wednesday, 10 April 2019 16:58:36 UTC-7, Ian Lance Taylor wrote:
>
> On Wed, Apr 10, 2019 at 4:34 PM vaastav anand > wrote:
> >
> > Is the debug info e
Is the debug info exported in the binary in DWARF format? And if so would
this package work https://golang.org/pkg/debug/dwarf/?
What about the global variables or the ones allocated on the heap? Are they
also not available inside the runtime either?
On Wednesday, 10 April 2019 13:28:49 UTC-7, I
11 matches
Mail list logo
