Re: [go-nuts] Re: memory issues
You could actually make a stress test inside a main_test.go with a
benchmark for example, run that locally and see.
It works over here btw.
package main_test
import (
"net/http"
"net/http/httptest"
"testing"
"github.com/gorilla/mux"
"github.com/stretchr/testify/assert"
)
func pingServer(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("pong"))
}
func Router() *mux.Router {
router := mux.NewRouter()
router.HandleFunc("/ping", pingServer).Methods("GET")
return router
}
func Test_Ping(t *testing.T) {
r, _ := http.NewRequest("GET", "/ping", nil)
w := httptest.NewRecorder()
Router().ServeHTTP(w, r)
assert.Equal(t, 200, w.Code, "OK response is expected")
}
func Benchmark_Ping(b *testing.B) {
r, _ := http.NewRequest("GET", "/ping", nil)
w := httptest.NewRecorder()
b.ResetTimer()
for i := 0; i < b.N; i++ { // use b.N for looping
Router().ServeHTTP(w, r)
assert.Equal(b, 200, w.Code, "OK response is expected")
}
}
Op vr 10 feb. 2023 om 00:47 schreef James Dornan :
> I did, with the same results.
>
> I've attached stack trace from docker logs and the files to recreate this
> issue, Dockerfile and main.go.
>
> Steps to recreate
> docker build -t pingtest .
>
> docker run -p 8001:80 pingtest
>
> ab -c 500 -n 5 http://localhost:8001/ping
>
> The result for my, from ab, was this.
> ab -c 500 -n 5 http://10.1.1.101:8001/ping
>
>─╯
> This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking 10.1.1.101 (be patient)
>
> Test aborted after 10 failures
>
> apr_socket_connect(): Connection reset by peer (104)
> Total of 366 requests completed
>
> On Thursday, February 9, 2023 at 3:02:08 AM UTC-5 Marcello H wrote:
>
>> I would trim down the problem, by making a very small program that gets
>> the XML file from a local disk and then just do the XSLT on it.
>> That would give you less environment to oversee and debug.
>> Perhaps then, make the xml as small as possible.
>> Also mention which libs you use or make a playground version of the
>> problem, so people might be able to understand more about the problem.
>>
>> Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan:
>>
>>> I have a go web service that acts as a proxy that gets XML documents
>>> from a remote system and processes them through XSLT, returning the result,
>>> if any. I have tried a number of options over the last few days and cannot
>>> seem to nail down the cause.
>>>
>>> Does anyone know how to address this or debug the issue? Thanks.
>>>
>>> Version 1.20 (on Alpine Linux 3.17)
>>>
>>> Build statement
>>>
>>> go build \
>>> -tags musl \
>>> -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \
>>> -gcflags=all="-wb=false -d=checkptr" \
>>> -a main.go
>>>
>>> runtime: marked free object in span 0x7f58c3422308, elemsize=96
>>> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr)
>>> 0xc000398000 alloc marked
>>> 0xc000398060 alloc marked
>>> 0xc0003980c0 alloc marked
>>> 0xc000398120 free unmarked
>>> 0xc000398180 free unmarked
>>> 0xc0003981e0 free unmarked
>>> 0xc000398240 alloc marked
>>> 0xc0003982a0 alloc marked
>>> 0xc000398300 free unmarked
>>> 0xc000398360 alloc marked
>>> 0xc0003983c0 alloc marked
>>> 0xc000398420 alloc marked
>>> 0xc000398480 free unmarked
>>> 0xc0003984e0 free unmarked
>>> 0xc000398540 free unmarked
>>> 0xc0003985a0 free unmarked
>>> 0xc000398600 free unmarked
>>> 0xc000398660 free unmarked
>>> 0xc0003986c0 free unmarked
>>> 0xc000398720 free unmarked
>>> 0xc000398780 free unmarked
>>> 0xc0003987e0 alloc marked
>>> 0xc000398840 alloc marked
>>> 0xc0003988a0 free unmarked
>>> 0xc000398900 free unmarked
>>> 0xc000398960 free unmarked
>>> 0xc0003989c0 free unmarked
>>> 0xc000398a20 free unmarked
>>> 0xc000398a80 free unmarked
>>> 0xc000398ae0 free unmarked
>>> 0xc000398b40 free unmarked
>>> 0xc000398ba0 free unmarked
>>> 0xc000398c00 free unmarked
>>> 0xc000398c60 free unmarked
>>> 0xc000398cc0 free unmarked
>>> 0xc000398d20 free unmarked
>>> 0xc000398d80 free unmarked
>>> 0xc000398de0 free unmarked
>>> 0xc000398e40 free unmarked
>>> 0xc000398ea0 free unmarked
>>> 0xc000398f00 alloc marked
>>> 0xc000398f60 free unmarked
>>> 0xc000398fc0 alloc marked
>>> 0xc000399020 alloc marked
>>> 0xc000399080 free unmarked
>>> 0xc0003990e0 free unmarked
>>> 0xc000399140 alloc marked
>>> 0xc0003991a0 alloc marked
>>> 0xc000399200 alloc marked
>>> 0xc000399260 free unmarked
>>> 0xc0003992c0 free unmarked
>>> 0xc000399320 free unmarked
>>> 0xc000399380 free unmarked
>>> 0xc0003993e0 free unmarked
>>> 0xc000399440 free unmarked
>>> 0xc0003994a0 free unmarked
>>> 0xc000399500 free unmarked
>>> 0xc000399560 free unmarked
>>> 0xc0003995c0 free unmarked
>>> 0xc000399620 alloc marked
>>> 0xc000399680 free unmarked
>>> 0xc0003996e0
[go-nuts] Re: memory issues
I did, with the same results. I've attached stack trace from docker logs and the files to recreate this issue, Dockerfile and main.go. Steps to recreate docker build -t pingtest . docker run -p 8001:80 pingtest ab -c 500 -n 5 http://localhost:8001/ping The result for my, from ab, was this. ab -c 500 -n 5 http://10.1.1.101:8001/ping ─╯ This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 10.1.1.101 (be patient) Test aborted after 10 failures apr_socket_connect(): Connection reset by peer (104) Total of 366 requests completed On Thursday, February 9, 2023 at 3:02:08 AM UTC-5 Marcello H wrote: > I would trim down the problem, by making a very small program that gets > the XML file from a local disk and then just do the XSLT on it. > That would give you less environment to oversee and debug. > Perhaps then, make the xml as small as possible. > Also mention which libs you use or make a playground version of the > problem, so people might be able to understand more about the problem. > > Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan: > >> I have a go web service that acts as a proxy that gets XML documents from >> a remote system and processes them through XSLT, returning the result, if >> any. I have tried a number of options over the last few days and cannot >> seem to nail down the cause. >> >> Does anyone know how to address this or debug the issue? Thanks. >> >> Version 1.20 (on Alpine Linux 3.17) >> >> Build statement >> >> go build \ >> -tags musl \ >> -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \ >> -gcflags=all="-wb=false -d=checkptr" \ >> -a main.go >> >> runtime: marked free object in span 0x7f58c3422308, elemsize=96 >> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr) >> 0xc000398000 alloc marked >> 0xc000398060 alloc marked >> 0xc0003980c0 alloc marked >> 0xc000398120 free unmarked >> 0xc000398180 free unmarked >> 0xc0003981e0 free unmarked >> 0xc000398240 alloc marked >> 0xc0003982a0 alloc marked >> 0xc000398300 free unmarked >> 0xc000398360 alloc marked >> 0xc0003983c0 alloc marked >> 0xc000398420 alloc marked >> 0xc000398480 free unmarked >> 0xc0003984e0 free unmarked >> 0xc000398540 free unmarked >> 0xc0003985a0 free unmarked >> 0xc000398600 free unmarked >> 0xc000398660 free unmarked >> 0xc0003986c0 free unmarked >> 0xc000398720 free unmarked >> 0xc000398780 free unmarked >> 0xc0003987e0 alloc marked >> 0xc000398840 alloc marked >> 0xc0003988a0 free unmarked >> 0xc000398900 free unmarked >> 0xc000398960 free unmarked >> 0xc0003989c0 free unmarked >> 0xc000398a20 free unmarked >> 0xc000398a80 free unmarked >> 0xc000398ae0 free unmarked >> 0xc000398b40 free unmarked >> 0xc000398ba0 free unmarked >> 0xc000398c00 free unmarked >> 0xc000398c60 free unmarked >> 0xc000398cc0 free unmarked >> 0xc000398d20 free unmarked >> 0xc000398d80 free unmarked >> 0xc000398de0 free unmarked >> 0xc000398e40 free unmarked >> 0xc000398ea0 free unmarked >> 0xc000398f00 alloc marked >> 0xc000398f60 free unmarked >> 0xc000398fc0 alloc marked >> 0xc000399020 alloc marked >> 0xc000399080 free unmarked >> 0xc0003990e0 free unmarked >> 0xc000399140 alloc marked >> 0xc0003991a0 alloc marked >> 0xc000399200 alloc marked >> 0xc000399260 free unmarked >> 0xc0003992c0 free unmarked >> 0xc000399320 free unmarked >> 0xc000399380 free unmarked >> 0xc0003993e0 free unmarked >> 0xc000399440 free unmarked >> 0xc0003994a0 free unmarked >> 0xc000399500 free unmarked >> 0xc000399560 free unmarked >> 0xc0003995c0 free unmarked >> 0xc000399620 alloc marked >> 0xc000399680 free unmarked >> 0xc0003996e0 free marked zombie >> 0x00c0003996e0: 0x00c000104b60 0x >> 0x00c0003996f0: 0x 0x >> 0x00c000399700: 0x 0x >> 0x00c000399710: 0x0100 0x >> 0x00c000399720: 0x 0x >> 0x00c000399730: 0x 0x >> 0xc000399740 free unmarked >> 0xc0003997a0 alloc marked >> 0xc000399800 alloc marked >> 0xc000399860 free unmarked >> 0xc0003998c0 free unmarked >> 0xc000399920 free unmarked >> 0xc000399980 free unmarked >> 0xc0003999e0 free unmarked >> 0xc000399a40 free unmarked >> 0xc000399aa0 free unmarked >> 0xc000399b00 free unmarked >> 0xc000399b60 free unmarked >> 0xc000399bc0 free unmarked >> 0xc000399c20 free unmarked >> 0xc000399c80 free unmarked >> 0xc000399ce0 free unmarked >> 0xc000399d40 free unmarked >> 0xc000399da0 free unmarked >> 0xc000399e00 free unmarked >> 0xc000399e60 free unmarked >>
Re: [go-nuts] Error Handling
I agree with Axel that a function like errReturn is a bad idea, though if
Go updates/improves error handling, it's possible we'll get something like
that (some of the error handling proposals have been similar to errReturn).
However, I don't see anything wrong with a function like Richard's
errHandle(), *if it's at the top level in main*. I often have a function
like this in main.go for CLIs. The signature might be:
inFile, err := os.ReadFile("Mydata.txt")
exitOnError(err, "cannot read file")
-Ben
On Wednesday, February 8, 2023 at 11:01:53 AM UTC+13 Richard Masci wrote:
> You said: "and FTR, I'd also consider your function a bad idea, but that's
> none of my business" <- I'll be the first to say not all my ideas are good
> ones, maybe this one isn't? Thanks for your response.
>
>
> On Tue, Feb 7, 2023 at 4:45 PM Axel Wagner
> wrote:
>
>> No, that is not possible. Only a `return` statement can return.
>> You *can* unwind the stack, using `panic` or `runtime.GoExit` (which is
>> what `t.Fatal` does) but it's a bad idea in general (and FTR, I'd also
>> consider your function a bad idea, but that's none of my business).
>>
>> On Tue, Feb 7, 2023 at 10:39 PM Rich wrote:
>>
>>> In most of my code I create a function to handle errors. looks something
>>> like this:
>>>
>>> func errorHandle(err error, str string, ex bool) {
>>> if err != nil {
>>> fmt.Printf("error: %s -- %v\n",str, err)
>>> }
>>> if ex {
>>> os.Exit(1)
>>> }
>>> }
>>>
>>> This cleans up my code:
>>> inFile, err := os.ReadFile("Mydata.txt")
>>> errorHandle(err,"read mydata.txt",true) // The true will exit
>>>
>>> So you see that I can exit the program when there is an error, what I
>>> want to know is if it's possible to do the same thing inside a function, to
>>> where I don't exit the program but return from the function:
>>>
>>> func OpenFile( filename string) []byte {
>>> inFile,err := os.ReadFile(filename)
>>> errReturn(err, "read "+filname,true)
>>>
>>> When there is an error it would return from the OpenFile function,
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/c77b336e-85a8-4e3e-a64d-e5e3f1759c68n%40googlegroups.com.
Re: [go-nuts] GO generics - function implementation
These look like homework assignments. You should be aware that if that's
the case, you are essentially throwing away the money you are spending on
your education by refusing to learn what it's trying to teach - that is,
you are paying for a product that you don't want.
That being said (who am I to judge), the solutions are very straight
forward:
func Partition[S any, K comparable](slice []S, fn func(S) K) map[K][]S {
m := make(map[K][]S)
for _, e := range slice {
k := fn(e)
m[k] = append(m[k], e)
}
return m
}
func Select[S any](slice []S, fn func(S) bool) []S {
var out []S
for _, e := range slice {
if fn(e) {
out = append(out, e)
}
}
return out
}
On Thu, Feb 9, 2023 at 8:26 PM Stanimir Stankov wrote:
> Need help!
> a function that allows you to group the elements of a slice based on a
> passed function that returns a key for each element of the slice
>
> func Partition[S any, K comparable](slice []S, fn func(S) K) map[K][]S { }
>
>
> a function that allows you to select elements from a slice
> based on a given predicate function
>
> func Select[S any](slice []S, fn func(S) bool) []S {}
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/61fffde8-d9cb-43c8-822e-557d3a5b4a0dn%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHPgwRcn_%2BSyW9DSY7ha8PB3FxVzujDHGtXPniGD%2BNohA%40mail.gmail.com.
Re: [go-nuts] Parsing time with timezones seem to fail
On Thu, Feb 9, 2023 at 11:26 AM 'Thomas Casteleyn' via golang-nuts wrote: > > Hi, I originally asked on Gophers slack where they directed me to this group. > > It seems I'm not able to parse these 2 timestamps with timezone correctly: > https://go.dev/play/p/VZwD29701ps > > The responses show confusing time formats and the playground even seems to be > more wrong than on my local machine. > > How should I correctly parse both timestamps in Go? It's not clear to me what you are actually trying to do. ParseInLocation will look for a timezone name like CET or MST relative to the location that you give it. This approach is used because identifiers like CET or MST are ambiguous. So in general it's odd to use ParseInLocation with an arbitrary timezone identifier. What is your actual goal? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXgVMO8N-Qfu8Q%2BOpycv1_V6re5m8KVe7Uw0R1PWS9GUA%40mail.gmail.com.
[go-nuts] GO generics - function implementation
Need help!
a function that allows you to group the elements of a slice based on a
passed function that returns a key for each element of the slice
func Partition[S any, K comparable](slice []S, fn func(S) K) map[K][]S { }
a function that allows you to select elements from a slice
based on a given predicate function
func Select[S any](slice []S, fn func(S) bool) []S {}
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/61fffde8-d9cb-43c8-822e-557d3a5b4a0dn%40googlegroups.com.
[go-nuts] Parsing time with timezones seem to fail
Hi, I originally asked on Gophers slack where they directed me to this group. It seems I'm not able to parse these 2 timestamps with timezone correctly: https://go.dev/play/p/VZwD29701ps The responses show confusing time formats and the playground even seems to be more wrong than on my local machine. How should I correctly parse both timestamps in Go? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6b7dcc2b-28a3-457f-a04c-f9c5dbf0a270n%40googlegroups.com.
[go-nuts] [security] Go 1.20.1 and Go 1.19.6 pre-announcement
Hello gophers, We plan to issue Go 1.20.1 and Go 1.19.6 during US business hours on Tuesday, February 14. These minor releases include PRIVATE security fixes to the standard library. Following our security policy, this is the pre-announcement of those releases. Thanks, The Go team -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/eeZk3o4VR7ihMgVFCGIeaQ%40geopod-ismtpd-5-0.
[go-nuts] Re: memory issues
What Marcello said!
But also, the message mentions bad use of Unsafe.Pointer. You might want to
look at uses in your app, and even third party libraries. See the
documentation: https://pkg.go.dev/unsafe#Pointer - The rules must be
followed to the letter!
Are you using cgo? It also has very specific rules.
On Thursday, February 9, 2023 at 3:02:08 AM UTC-5 Marcello H wrote:
> I would trim down the problem, by making a very small program that gets
> the XML file from a local disk and then just do the XSLT on it.
> That would give you less environment to oversee and debug.
> Perhaps then, make the xml as small as possible.
> Also mention which libs you use or make a playground version of the
> problem, so people might be able to understand more about the problem.
>
> Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan:
>
>> I have a go web service that acts as a proxy that gets XML documents from
>> a remote system and processes them through XSLT, returning the result, if
>> any. I have tried a number of options over the last few days and cannot
>> seem to nail down the cause.
>>
>> Does anyone know how to address this or debug the issue? Thanks.
>>
>> Version 1.20 (on Alpine Linux 3.17)
>>
>> Build statement
>>
>> go build \
>> -tags musl \
>> -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \
>> -gcflags=all="-wb=false -d=checkptr" \
>> -a main.go
>>
>> runtime: marked free object in span 0x7f58c3422308, elemsize=96
>> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr)
>> 0xc000398000 alloc marked
>> 0xc000398060 alloc marked
>> 0xc0003980c0 alloc marked
>> 0xc000398120 free unmarked
>> 0xc000398180 free unmarked
>> 0xc0003981e0 free unmarked
>> 0xc000398240 alloc marked
>> 0xc0003982a0 alloc marked
>> 0xc000398300 free unmarked
>> 0xc000398360 alloc marked
>> 0xc0003983c0 alloc marked
>> 0xc000398420 alloc marked
>> 0xc000398480 free unmarked
>> 0xc0003984e0 free unmarked
>> 0xc000398540 free unmarked
>> 0xc0003985a0 free unmarked
>> 0xc000398600 free unmarked
>> 0xc000398660 free unmarked
>> 0xc0003986c0 free unmarked
>> 0xc000398720 free unmarked
>> 0xc000398780 free unmarked
>> 0xc0003987e0 alloc marked
>> 0xc000398840 alloc marked
>> 0xc0003988a0 free unmarked
>> 0xc000398900 free unmarked
>> 0xc000398960 free unmarked
>> 0xc0003989c0 free unmarked
>> 0xc000398a20 free unmarked
>> 0xc000398a80 free unmarked
>> 0xc000398ae0 free unmarked
>> 0xc000398b40 free unmarked
>> 0xc000398ba0 free unmarked
>> 0xc000398c00 free unmarked
>> 0xc000398c60 free unmarked
>> 0xc000398cc0 free unmarked
>> 0xc000398d20 free unmarked
>> 0xc000398d80 free unmarked
>> 0xc000398de0 free unmarked
>> 0xc000398e40 free unmarked
>> 0xc000398ea0 free unmarked
>> 0xc000398f00 alloc marked
>> 0xc000398f60 free unmarked
>> 0xc000398fc0 alloc marked
>> 0xc000399020 alloc marked
>> 0xc000399080 free unmarked
>> 0xc0003990e0 free unmarked
>> 0xc000399140 alloc marked
>> 0xc0003991a0 alloc marked
>> 0xc000399200 alloc marked
>> 0xc000399260 free unmarked
>> 0xc0003992c0 free unmarked
>> 0xc000399320 free unmarked
>> 0xc000399380 free unmarked
>> 0xc0003993e0 free unmarked
>> 0xc000399440 free unmarked
>> 0xc0003994a0 free unmarked
>> 0xc000399500 free unmarked
>> 0xc000399560 free unmarked
>> 0xc0003995c0 free unmarked
>> 0xc000399620 alloc marked
>> 0xc000399680 free unmarked
>> 0xc0003996e0 free marked zombie
>> 0x00c0003996e0: 0x00c000104b60 0x
>> 0x00c0003996f0: 0x 0x
>> 0x00c000399700: 0x 0x
>> 0x00c000399710: 0x0100 0x
>> 0x00c000399720: 0x 0x
>> 0x00c000399730: 0x 0x
>> 0xc000399740 free unmarked
>> 0xc0003997a0 alloc marked
>> 0xc000399800 alloc marked
>> 0xc000399860 free unmarked
>> 0xc0003998c0 free unmarked
>> 0xc000399920 free unmarked
>> 0xc000399980 free unmarked
>> 0xc0003999e0 free unmarked
>> 0xc000399a40 free unmarked
>> 0xc000399aa0 free unmarked
>> 0xc000399b00 free unmarked
>> 0xc000399b60 free unmarked
>> 0xc000399bc0 free unmarked
>> 0xc000399c20 free unmarked
>> 0xc000399c80 free unmarked
>> 0xc000399ce0 free unmarked
>> 0xc000399d40 free unmarked
>> 0xc000399da0 free unmarked
>> 0xc000399e00 free unmarked
>> 0xc000399e60 free unmarked
>> 0xc000399ec0 free unmarked
>> 0xc000399f20 free unmarked
>> 0xc000399f80 free unmarked
>> fatal error: found pointer to free object
>>
>> runtime stack:
>> runtime.throw({0x84f468?, 0xc000399740?})
>> /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7f589bc43780
>> sp=0x7f589bc43750 pc=0x4357fd
>> runtime.(*mspan).reportZombies(0x7f58c3422308)
>> /usr/local/go/src/runtime/mgcsweep.go:846 +0x2e5
>> fp=0x7f589bc43800 sp=0x7f589bc43780 pc=0x424d25
>> runtime.(*sweepLocked).sweep(0x7f589bc43928?, 0x0)
>>
[go-nuts] [security] golang.org/x/image/tiff fix pre-announcement
Hello gophers, We plan to issue a security fix for the golang.org/x/image/tiff package in the golang.org/x/image module on Tuesday, February 14th. Following our security policy, this is the pre-announcement of that fix. Cheers, Roland on behalf of the Go team -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CADAOFNTmpjSPCqFX2dAtm0VOk7fGS83rOmJBTankp61Rc4gq1g%40mail.gmail.com.
[go-nuts] Re: Go, VSCODE IDE, Delve debugger: am having problem debugging my console app
Hi, I can not get the console app to run with the debugger. When I start the debugger I do not get the console display only Starting: C:\Users\djankins\go\bin\dlv.exe dap --listen=127.0.0.1:52239 from c:\Users\djankins\Repositories\UT\adpf-simulation\GUI DAP server listening at: 127.0.0.1:52239 Type 'dlv help' for list of commands. On Wednesday, January 31, 2018 at 12:50:02 AM UTC-5 evan wrote: > i can debug my web app server code with no problem with the Go, VSCODE, > and Delve setup. > > the client connecting to that web app is a console app, which primarily > does the following: > > gets json data from the server, stuffs the data into the table widget of > the terminal user interface (3rd party Go package) for display, lets users > edit the data, etc > > the console app runs fine when i go run client.go. but when i want to > debug the code, the client app doesn't show up :-) > > so i'm currently forced to log println's out to a file so i can keep > moving forward. > > any suggestion what i can do so that i can start up my console app in > debug mode and when it shows up, interact with it until i get to preset > breakpoints, etc (or other set of steps that might work)? > > i'm working in a windows 10 development machine, go version 1.9.2, and > VSCODE 1.19.3 > > thanks for any help! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7567bc07-664e-4da8-9522-40a770e81ecan%40googlegroups.com.
[go-nuts] SIGSEGV: segmentation violation on Linux/ARM with Microchip SAM9x60 (ARM926 core) processor
A user filled https://gitlab.com/cznic/sqlite/-/issues/132, but I'm not able to reproduce it on RPi 4 and I don't have access to the subj. chip/system. It might be possibly something HW related, IDK. Looking for expert advice for the linux/arm Go target. Anyone out there? Thanks in advance. -j -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA40n-UCwbFz6dt6_GGr2D4vaMmA%3D9hD8dYb%3DnefsHyboA%2BOjA%40mail.gmail.com.
[go-nuts] Re: [golang-dev] Importing .xls and .xlsx files with golang.
(golang-...@googlegroups.com is for developing the Go language (bcc-d), you'll want to use golang-nuts@googlegroups.com, now on cc.) If I understand correctly, you plan to parse excel files. I haven't tried these just yet, but maybe search on https://pkg.go.dev/search?q=xls best, fgergo On 2/8/23, Aadi Sharma wrote: > Can we import the files with extension *.xls* and *.xlsx*, such as we > import *.csv* files with golang. > > -- > You received this message because you are subscribed to the Google Groups > "golang-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-dev/2c6ee11f-e948-4854-ac91-8709bb9ef9fcn%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bctqrqkq0ZA3NCd3_21VfZt5B_w5kQfpj8dc2XHzW31oryggw%40mail.gmail.com.
[go-nuts] Re: memory issues
I would trim down the problem, by making a very small program that gets the
XML file from a local disk and then just do the XSLT on it.
That would give you less environment to oversee and debug.
Perhaps then, make the xml as small as possible.
Also mention which libs you use or make a playground version of the
problem, so people might be able to understand more about the problem.
Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan:
> I have a go web service that acts as a proxy that gets XML documents from
> a remote system and processes them through XSLT, returning the result, if
> any. I have tried a number of options over the last few days and cannot
> seem to nail down the cause.
>
> Does anyone know how to address this or debug the issue? Thanks.
>
> Version 1.20 (on Alpine Linux 3.17)
>
> Build statement
>
> go build \
> -tags musl \
> -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \
> -gcflags=all="-wb=false -d=checkptr" \
> -a main.go
>
> runtime: marked free object in span 0x7f58c3422308, elemsize=96
> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr)
> 0xc000398000 alloc marked
> 0xc000398060 alloc marked
> 0xc0003980c0 alloc marked
> 0xc000398120 free unmarked
> 0xc000398180 free unmarked
> 0xc0003981e0 free unmarked
> 0xc000398240 alloc marked
> 0xc0003982a0 alloc marked
> 0xc000398300 free unmarked
> 0xc000398360 alloc marked
> 0xc0003983c0 alloc marked
> 0xc000398420 alloc marked
> 0xc000398480 free unmarked
> 0xc0003984e0 free unmarked
> 0xc000398540 free unmarked
> 0xc0003985a0 free unmarked
> 0xc000398600 free unmarked
> 0xc000398660 free unmarked
> 0xc0003986c0 free unmarked
> 0xc000398720 free unmarked
> 0xc000398780 free unmarked
> 0xc0003987e0 alloc marked
> 0xc000398840 alloc marked
> 0xc0003988a0 free unmarked
> 0xc000398900 free unmarked
> 0xc000398960 free unmarked
> 0xc0003989c0 free unmarked
> 0xc000398a20 free unmarked
> 0xc000398a80 free unmarked
> 0xc000398ae0 free unmarked
> 0xc000398b40 free unmarked
> 0xc000398ba0 free unmarked
> 0xc000398c00 free unmarked
> 0xc000398c60 free unmarked
> 0xc000398cc0 free unmarked
> 0xc000398d20 free unmarked
> 0xc000398d80 free unmarked
> 0xc000398de0 free unmarked
> 0xc000398e40 free unmarked
> 0xc000398ea0 free unmarked
> 0xc000398f00 alloc marked
> 0xc000398f60 free unmarked
> 0xc000398fc0 alloc marked
> 0xc000399020 alloc marked
> 0xc000399080 free unmarked
> 0xc0003990e0 free unmarked
> 0xc000399140 alloc marked
> 0xc0003991a0 alloc marked
> 0xc000399200 alloc marked
> 0xc000399260 free unmarked
> 0xc0003992c0 free unmarked
> 0xc000399320 free unmarked
> 0xc000399380 free unmarked
> 0xc0003993e0 free unmarked
> 0xc000399440 free unmarked
> 0xc0003994a0 free unmarked
> 0xc000399500 free unmarked
> 0xc000399560 free unmarked
> 0xc0003995c0 free unmarked
> 0xc000399620 alloc marked
> 0xc000399680 free unmarked
> 0xc0003996e0 free marked zombie
> 0x00c0003996e0: 0x00c000104b60 0x
> 0x00c0003996f0: 0x 0x
> 0x00c000399700: 0x 0x
> 0x00c000399710: 0x0100 0x
> 0x00c000399720: 0x 0x
> 0x00c000399730: 0x 0x
> 0xc000399740 free unmarked
> 0xc0003997a0 alloc marked
> 0xc000399800 alloc marked
> 0xc000399860 free unmarked
> 0xc0003998c0 free unmarked
> 0xc000399920 free unmarked
> 0xc000399980 free unmarked
> 0xc0003999e0 free unmarked
> 0xc000399a40 free unmarked
> 0xc000399aa0 free unmarked
> 0xc000399b00 free unmarked
> 0xc000399b60 free unmarked
> 0xc000399bc0 free unmarked
> 0xc000399c20 free unmarked
> 0xc000399c80 free unmarked
> 0xc000399ce0 free unmarked
> 0xc000399d40 free unmarked
> 0xc000399da0 free unmarked
> 0xc000399e00 free unmarked
> 0xc000399e60 free unmarked
> 0xc000399ec0 free unmarked
> 0xc000399f20 free unmarked
> 0xc000399f80 free unmarked
> fatal error: found pointer to free object
>
> runtime stack:
> runtime.throw({0x84f468?, 0xc000399740?})
> /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7f589bc43780
> sp=0x7f589bc43750 pc=0x4357fd
> runtime.(*mspan).reportZombies(0x7f58c3422308)
> /usr/local/go/src/runtime/mgcsweep.go:846 +0x2e5 fp=0x7f589bc43800
> sp=0x7f589bc43780 pc=0x424d25
> runtime.(*sweepLocked).sweep(0x7f589bc43928?, 0x0)
> /usr/local/go/src/runtime/mgcsweep.go:634 +0x9f6 fp=0x7f589bc438f0
> sp=0x7f589bc43800 pc=0x424696
> runtime.(*mcentral).uncacheSpan(0x7f589bdf73b8?, 0xc00029a000?)
> /usr/local/go/src/runtime/mcentral.go:228 +0xa5 fp=0x7f589bc43918
> sp=0x7f589bc438f0 pc=0x416da5
> runtime.(*mcache).releaseAll(0x7f58c34173c8)
> /usr/local/go/src/runtime/mcache.go:291 +0x145 fp=0x7f589bc43980
> sp=0x7f589bc43918 pc=0x416805
> runtime.(*mcache).prepareForSweep(0x7f58c34173c8)
> /usr/local/go/src/runtime/mcache.go:328
