Re: [go-nuts] Symbol of const string are not exported by compiler
Your question should have included more information such as the Go version.
Nonetheless, I don't see how Delve is able to resolve "myValueInt" in your
example. I modified your code to include non-const versions of the symbols:
package main
import "fmt"
const constValueStr = "abc"
const constValueInt = 12
const constValueFloat = 1.2
var varValueStr = "def"
var varValueInt = 13
func main() {
fmt.Println(constValueStr, constValueInt, constValueFloat,
varValueStr, varValueInt)
}
I put that code in a file named "x.go" and compiled it with "go build
x.go". The "strings" command shows both "varValue" symbols but neither
"constValue" symbols:
elvish> strings - x | grep varValue
_main.varValueInt
_main.varValueStr
elvish> strings - x | grep constValue
Exception: grep exited with 1
[tty 156]:1:15-29: strings - x | grep constValue
Delve is able to resolve three of the five symbols:
elvish> dlv exec x
Type 'help' for list of commands.
(dlv) print main.varValueInt
13
(dlv) print main.constValueInt
12
(dlv) print main.constValueFloat
Command failed: could not find symbol value for main
(dlv) print main.varValueStr
(unreadable could not read string at 0x100086f47 due to protocol error E08
during memory read for packet $m100086f47,3)
(dlv) print main.constValueStr
Command failed: could not find symbol value for main
It is not obvious how Delve is able to resolve "main.constValueInt" since
that string does not appear in the binary according to the "strings - x"
command. So I think the more interesting question is how Delve is able to
resolve the "main.constValueInt" symbol but not the two other const symbols.
On Thu, May 30, 2024 at 1:58 AM Benoît Marguerie wrote:
> or, in a easier way, a full "copy/paste" example of code:
>
> package main
>
> import "fmt"
>
> const myValueStr = "try"
> const myValueInt = 12
>
> func main() {
> fmt.Println("Instruction only to put a breakpoint")
> }
>
>
> Le jeudi 30 mai 2024 à 10:53:50 UTC+2, Benoît Marguerie a écrit :
>
>> Of course!
>> The code can be really simple like this:
>>
>>
>> *const myValueStr = "try"const myValueInt = 12*
>>
>>
>>
>> *func DoSomething() { fmt.Println("Instruction only to put a
>> breakpoint")}*
>>
>>
>> and the result with delve:
>>
>>
>>
>>
>>
>> *(dlv) print %v myValueInt12(dlv) print %v myValueStrCommand failed:
>> could not find symbol value for myValueStr*
>>
>> Benoit
>>
> --
> 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/c938f107-9bca-4b8e-a10c-f8deef396c87n%40googlegroups.com
>
> .
>
--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank
--
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/CABx2%3DD--TKEdowrJdOFT%3Dgz5gTPZPWyyf42pHwkb8Jv0GxNDXg%40mail.gmail.com.
[go-nuts] [security] Go 1.22.4 and Go 1.21.11 pre-announcement
Hello gophers, We plan to issue Go 1.22.4 and Go 1.21.11 during US business hours on Tuesday, June 4. These minor releases include PRIVATE security fixes to the standard library, covering the following CVE: - CVE-2024-24790 Following our security policy, this is the pre-announcement of those releases. Thanks, Matthew and Carlos for 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/hro34FA2QbSJZ-wwA7vkTQ%40geopod-ismtpd-25.
Re: [go-nuts] Memory operations hung in semacquire state, GC routine parked while holding semaphore?
Thanks for the response Michael.
> It looks like a Windows minidump (unsurprisingly) can't follow the
relation. A regular goroutine stack trace dump that gets emitted on a
forced exit or crash is able to show both sides of the system stack switch
with a little bit of configuration.
Yeah, that was my understanding too. Again, not a windows expert, but my
understanding is that there's no equivalent to the "send SIGABRT to get a
stack dump" trick on windows?
I didn't file a bug initially, as this version appears to be more than two
minor releases behind, and I also wasn't completely sure if it was a bug or
some weird AV/VM behavior.
The entire stack trace is pretty huge, so I put it here:
https://gist.github.com/fearful-symmetry/1e6546640f667731b3fe2a90f96b5680
On Wednesday, May 29, 2024 at 9:26:50 PM UTC-7 Michael Knyszek wrote:
> The example goroutine in the original post is parked waiting for some
> other goroutine to finish up the GC cycle. Somewhere, a goroutine is
> getting stuck trying to finish it up, which could possibly be a deadlock.
> (I am especially suspicious of a deadlock bug because most threads are
> stopped there.) It would be good to confirm whether application CPU time
> drops to zero or plateaus to some very consistent number, which would
> support the deadlock theory.
>
> On Wednesday, May 29, 2024 at 11:09:30 AM UTC-4 robert engels wrote:
>
> I am pretty sure runtime is supposed to crash the process if it slows the
> allocators “too much” (I believe there are some config settings to control
> this).
>
> The runtime never intentionally crashes a process due to rate or volume of
> allocation. There is an optional memory limit, but it's soft in that the
> runtime gives up trying to maintain the limit at some point; see below and
> see https://go.dev/doc/gc-guide.
>
>
> If you have enough Go routines it may look like they are hung - you need
> to track specific routines by their ID. The stack certainly looks like it
> is trying to allocate memory for a slice - and it is being paused - because
> it is waiting on the GC lock.
>
> Are you doing any native code? You could have heap corruption and that is
> also why the GC thread is getting hung.
>
> If the GC thread makes progress albeit slowly - I would settle on my first
> guess - memory leak...
>
> I suspect a memory leak is not at play here. In the case of a memory leak,
> by default, your live heap may steadily increase, and the time between GC
> cycles increases proportionally. The GC is designed such that the overall
> impact should stay roughly constant as your heap grows by default. In this
> case, memory leak should appear exactly as expected: a rise in memory use
> over time.
>
> If GOMEMLIMIT is in use (which is non-default; you have to ask for it),
> then a memory leak may result in progressively more frequent GC cycles.
> However, the worst-case failure to make progress ("GC death spiral") should
> be prevented in practice by the runtime already. It puts a hard limit on
> the amount of CPU time that can be taken by the GC every CPU-second,
> instead letting memory use increase. Don't get me wrong, it can still slow
> down the application a good bit, and maybe under some circumstances it'll
> still look like a hang. It is also possible there's a bug in the GC CPU
> limiter or something.
>
> But, from what I've seen so far in this bug, I'm more convinced of a
> deadlock bug than the application failing to make progress. Lots of
> goroutines lining up on gcMarkDone just sounds too specific to me.
>
>
> On May 29, 2024, at 10:00 AM, 'Alex Kristiansen' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> That's an interesting idea, I probably wouldn't have thought of that on my
> own. Is that expected behavior for memory pressure on Windows+golang? I
> don't have much windows experience, so my assumption would be that the
> Windows equivalent of the OOMKiller would kick in and just kill the
> application.
>
> On Tuesday, May 28, 2024 at 4:04:15 PM UTC-7 robert engels wrote:
>
> Feels like a memory leak to me. I would look for growing heap size in the
> gc logs. I am guessing that the system is not completely hung - but rather
> the runtime is having a hard time obtaining more memory, so it is slowing
> the allocators to a rate that makes them appear hung.
>
> It may be that the process has consumed nearly all of the OS memory too -
> so the OS is having a hard-time responding to malloc requests.
>
> i.e. The system is not making progress.
>
> On May 28, 2024, at 3:54 PM, 'Alex Kristiansen' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> This is an odd one. For reference, this is a customer machine, Windows
> server 2016, compiled with go1.20.11. The application just hangs after a
> number of days; windows minidump reveals that most threads are doing this:
>
> Goroutine 462 - User: unicode/utf16/utf16.go:106 unicode/utf16.Decode
> (0xe6e391) [semacquire]
>
Re: [go-nuts] Symbol of const string are not exported by compiler
or, in a easier way, a full "copy/paste" example of code:
package main
import "fmt"
const myValueStr = "try"
const myValueInt = 12
func main() {
fmt.Println("Instruction only to put a breakpoint")
}
Le jeudi 30 mai 2024 à 10:53:50 UTC+2, Benoît Marguerie a écrit :
> Of course!
> The code can be really simple like this:
>
>
> *const myValueStr = "try"const myValueInt = 12*
>
>
>
> *func DoSomething() { fmt.Println("Instruction only to put a
> breakpoint")}*
>
>
> and the result with delve:
>
>
>
>
>
> *(dlv) print %v myValueInt12(dlv) print %v myValueStrCommand failed: could
> not find symbol value for myValueStr*
>
> Benoit
>
--
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/c938f107-9bca-4b8e-a10c-f8deef396c87n%40googlegroups.com.
Re: [go-nuts] Symbol of const string are not exported by compiler
Of course!
The code can be really simple like this:
*const myValueStr = "try"const myValueInt = 12*
*func DoSomething() { fmt.Println("Instruction only to put a
breakpoint")}*
and the result with delve:
*(dlv) print %v myValueInt12(dlv) print %v myValueStrCommand failed: could
not find symbol value for myValueStr*
Benoit
--
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/89042acf-1a57-467e-8df4-f33fbd71415en%40googlegroups.com.
Re: [go-nuts] Symbol of const string are not exported by compiler
On Thu, May 30, 2024 at 10:34 AM Benoît Marguerie wrote: > I discovered a "strange" behavior doing a simple operation. > I defined 2 const : one integer and one string. With delve (or other > debugger), I'm able to consult the const integer value but not the const > string value. Delve team explained me that the go compiler doesn't export > symbol of const string. > > Sorry for the newbee's question but is there anybody knowing why the symbol > can be exported for an integer but not for a string ? Please include a code example that you're investigating using delve. I, for one, cannot infer enough information from your post to be sure what exactly is the problem and hence if the observed is - or is not - an expected outcome. -- 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-V0CAVBGHo-E1DgyA2cJaX8QjKRYNCgcGNu%2BkNL0Cg%3D0w%40mail.gmail.com.
[go-nuts] Symbol of const string are not exported by compiler
Hello All, I discovered a "strange" behavior doing a simple operation. I defined 2 const : one integer and one string. With delve (or other debugger), I'm able to consult the const integer value but not the const string value. Delve team explained me that the go compiler doesn't export symbol of const string. Sorry for the newbee's question but is there anybody knowing why the symbol can be exported for an integer but not for a string ? BR, Benoît -- 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/31d16661-566b-445f-a592-01c09dee0c05n%40googlegroups.com.
