FAQ
Hello,


I'm playing a bit with GDB + golang and I've found something that I'm not
really sure I understand why it is like that or if it's ok to be like that
or not.
If this has been answered before, I apologize, I've searched the group but
I haven't found something like this, please point me to the right post.
See below the program, output, environment and my questions:

demo.go: http://play.golang.org/p/dGBT7xECRs

package main

import "fmt"

func main() {
a := "Hello world!"
b := 1.12
c := false
var d [3]int
e := 2.21

f := b + e
if c {
fmt.Printf("a: %s \n", a)
fmt.Printf("f: %f \n", f)
fmt.Printf("f: %v \n", f)
} else {
fmt.Printf("f: %v \n", f)
fmt.Printf("f: %f \n", f)
fmt.Printf("a: %s \n", a)
}
fmt.Println("d: ", d)
}

------------------------------

Build command: go build -gcflags "-N -l" -o demo demo.go
gdb demo

------------------------------
break demo.go:6
break demo.go:13
run
info locals
a = <error reading variable: Address 0x4411e6 out of bounds>
b = 6,9533491646583695e-310
c = false
d = {140737353895936, 0, 100, 4316562, 16, 4816288, 0, 4461078, 4816288,
833492132160, 0, 100, 833492132160, 4409578, 4979216, 29, 140737353932416,
833492132160, 65, 4286192, 4198466, 4272079, 5651336, 0, 0, 4271792,
4294967296, -1, 0, 5651296, 0, 0, 4281584, 0 <repeats 96 times>}
e = 4,9406564584124654e-322
f = 0
run
info locals
info local
a = "Hello world!"
b = 1,1200000000000001
c = false
d = {0, 0, 0, 4316562, 16, 4816288, 0, 4921840, 12, 833492132160, 0, 100,
833492132160, 4409578, 4979216, 29, 140737353932416, 833492132160, 65,
4286192, 4198466, 4272079, 5651336, 0, 0, 4271792, 4294967296, -1, 0,
5651296, 0, 0, 4281584, 0 <repeats 96 times>}
e = 2,21
f = 3,3300000000000001

------------------------------

I'm using GO 1.2 from the official distribution on Ubuntu 13.10 with
kernel 3.12.7, GNU gdb (GDB) 7.6.1-ubuntu.
Since I'm running on this version of OS I've had to run 2to3 to convert the
runtime-gdb.py script to python3.

Here's what I don't understand:

    - why the variables look like that in memory before they are assigned in
    that form? Would it be better to have them initialized to 0? Is it because
    of the kernel / way memory is allocated by the go runtime or I'm way of?
    - why does the 'd' variable looks like that? While I could understand it
    before initialization, even if it should be 0 sized but maybe the answer is
    related to the above question, after the initialization shouldn't it be
    limited to only three values? I've tried with something like "var d [6]int"
    but then the number of elements goes down and it looks like this: "d =
    {4715168, 100, 140737353895984, 140737353895936, 0, 100, 4316562, 16,
    4816160, 0, 4461078, 4816160, 833492132160, 0, 100, 833492132160, 4409578,
    4979056, 29, 140737353932416, 833492132160, 65, 4286192, 4198466, 4272079,
    5651336, 0, 0, 4271792, 4294967296, -1, 0, 5651296, 0, 0, 4281584, 0
    <repeats 61 times>}"
    - why does "%v" produces a different output that "%f". According to the
    documentation: "%v the value in a default format." so shouldn't the output
    in this case be the one that "%f" produces?


I know that running the program will produce the expected output, besides
the last question, but I'm just curious why this is like it is.
Also, I would hope that the second point about the int array is just a
quirk in output from gdb, doesn't happen in normal programs (but I have no
clue how to check it out).

Note: I've tried GO 1.1.2 and it produces the same things.

Thank you for your time.


Kind regards,
Florin

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Florin Patan at Jan 16, 2014 at 9:37 pm
    Also, I've forgot to ask, why is there a difference in how b and e are
    allocated / represented?

    Kind regards,
    Florin

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jan 16, 2014 at 10:09 pm

    On Thu, Jan 16, 2014 at 1:27 PM, Florin Patan wrote:
    I'm playing a bit with GDB + golang and I've found something that I'm not
    really sure I understand why it is like that or if it's ok to be like that
    or not.
    If this has been answered before, I apologize, I've searched the group but I
    haven't found something like this, please point me to the right post.
    See below the program, output, environment and my questions:

    demo.go: http://play.golang.org/p/dGBT7xECRs

    package main

    import "fmt"

    func main() {
    a := "Hello world!"
    b := 1.12
    c := false
    var d [3]int
    e := 2.21

    f := b + e
    if c {
    fmt.Printf("a: %s \n", a)
    fmt.Printf("f: %f \n", f)
    fmt.Printf("f: %v \n", f)
    } else {
    fmt.Printf("f: %v \n", f)
    fmt.Printf("f: %f \n", f)
    fmt.Printf("a: %s \n", a)
    }
    fmt.Println("d: ", d)
    }

    ------------------------------

    Build command: go build -gcflags "-N -l" -o demo demo.go
    gdb demo

    ------------------------------
    break demo.go:6
    break demo.go:13
    run
    info locals
    a = <error reading variable: Address 0x4411e6 out of bounds>
    b = 6,9533491646583695e-310
    c = false
    d = {140737353895936, 0, 100, 4316562, 16, 4816288, 0, 4461078, 4816288,
    833492132160, 0, 100, 833492132160, 4409578, 4979216, 29, 140737353932416,
    833492132160, 65, 4286192, 4198466, 4272079, 5651336, 0, 0, 4271792,
    4294967296, -1, 0, 5651296, 0, 0, 4281584, 0 <repeats 96 times>}
    e = 4,9406564584124654e-322
    f = 0
    run
    info locals
    info local
    a = "Hello world!"
    b = 1,1200000000000001
    c = false
    d = {0, 0, 0, 4316562, 16, 4816288, 0, 4921840, 12, 833492132160, 0, 100,
    833492132160, 4409578, 4979216, 29, 140737353932416, 833492132160, 65,
    4286192, 4198466, 4272079, 5651336, 0, 0, 4271792, 4294967296, -1, 0,
    5651296, 0, 0, 4281584, 0 <repeats 96 times>}
    e = 2,21
    f = 3,3300000000000001

    ------------------------------

    I'm using GO 1.2 from the official distribution on Ubuntu 13.10 with kernel
    3.12.7, GNU gdb (GDB) 7.6.1-ubuntu.
    Since I'm running on this version of OS I've had to run 2to3 to convert the
    runtime-gdb.py script to python3.

    Here's what I don't understand:

    why the variables look like that in memory before they are assigned in that
    form? Would it be better to have them initialized to 0? Is it because of the
    kernel / way memory is allocated by the go runtime or I'm way of?
    Go, like most languages of its class, puts most local variables on the
    stack. The stack contains essentially random data. The variables are
    initialized by the function as it runs. It would be more accurate for
    gdb to say that the variable's value is not available before it has
    been initialized, but the gc compiler does not generate debug info
    that is sufficiently accurate for gdb to say that. So instead gdb
    displays whatever random values happen to be there.
    why does the 'd' variable looks like that? While I could understand it
    before initialization, even if it should be 0 sized but maybe the answer is
    related to the above question, after the initialization shouldn't it be
    limited to only three values? I've tried with something like "var d [6]int"
    but then the number of elements goes down and it looks like this: "d =
    {4715168, 100, 140737353895984, 140737353895936, 0, 100, 4316562, 16,
    4816160, 0, 4461078, 4816160, 833492132160, 0, 100, 833492132160, 4409578,
    4979056, 29, 140737353932416, 833492132160, 65, 4286192, 4198466, 4272079,
    5651336, 0, 0, 4271792, 4294967296, -1, 0, 5651296, 0, 0, 4281584, 0
    <repeats 61 times>}"
    I don't know. It looks like a bug either in the gc compiler or in the
    gdb Go support or in gdb proper.

    why does "%v" produces a different output that "%f". According to the
    documentation: "%v the value in a default format." so shouldn't the output
    in this case be the one that "%f" produces?
    The default format for a float64 value happens to be %g, not %f.
    Also, I've forgot to ask, why is there a difference in how b and e are allocated / represented?
    Read http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html .

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Florin Patan at Jan 16, 2014 at 11:36 pm

    On Thursday, January 16, 2014 11:09:03 PM UTC+1, Ian Lance Taylor wrote:
    On Thu, Jan 16, 2014 at 1:27 PM, Florin Patan wrote:

    I'm playing a bit with GDB + golang and I've found something that I'm not
    really sure I understand why it is like that or if it's ok to be like that
    or not.
    If this has been answered before, I apologize, I've searched the group but I
    haven't found something like this, please point me to the right post.
    See below the program, output, environment and my questions:

    demo.go: http://play.golang.org/p/dGBT7xECRs

    package main

    import "fmt"

    func main() {
    a := "Hello world!"
    b := 1.12
    c := false
    var d [3]int
    e := 2.21

    f := b + e
    if c {
    fmt.Printf("a: %s \n", a)
    fmt.Printf("f: %f \n", f)
    fmt.Printf("f: %v \n", f)
    } else {
    fmt.Printf("f: %v \n", f)
    fmt.Printf("f: %f \n", f)
    fmt.Printf("a: %s \n", a)
    }
    fmt.Println("d: ", d)
    }

    ------------------------------

    Build command: go build -gcflags "-N -l" -o demo demo.go
    gdb demo

    ------------------------------
    break demo.go:6
    break demo.go:13
    run
    info locals
    a = <error reading variable: Address 0x4411e6 out of bounds>
    b = 6,9533491646583695e-310
    c = false
    d = {140737353895936, 0, 100, 4316562, 16, 4816288, 0, 4461078, 4816288,
    833492132160, 0, 100, 833492132160, 4409578, 4979216, 29,
    140737353932416,
    833492132160, 65, 4286192, 4198466, 4272079, 5651336, 0, 0, 4271792,
    4294967296, -1, 0, 5651296, 0, 0, 4281584, 0 <repeats 96 times>}
    e = 4,9406564584124654e-322
    f = 0
    run
    info locals
    info local
    a = "Hello world!"
    b = 1,1200000000000001
    c = false
    d = {0, 0, 0, 4316562, 16, 4816288, 0, 4921840, 12, 833492132160, 0, 100,
    833492132160, 4409578, 4979216, 29, 140737353932416, 833492132160, 65,
    4286192, 4198466, 4272079, 5651336, 0, 0, 4271792, 4294967296, -1, 0,
    5651296, 0, 0, 4281584, 0 <repeats 96 times>}
    e = 2,21
    f = 3,3300000000000001

    ------------------------------

    I'm using GO 1.2 from the official distribution on Ubuntu 13.10 with kernel
    3.12.7, GNU gdb (GDB) 7.6.1-ubuntu.
    Since I'm running on this version of OS I've had to run 2to3 to convert the
    runtime-gdb.py script to python3.

    Here's what I don't understand:

    why the variables look like that in memory before they are assigned in that
    form? Would it be better to have them initialized to 0? Is it because of the
    kernel / way memory is allocated by the go runtime or I'm way of?
    Go, like most languages of its class, puts most local variables on the
    stack. The stack contains essentially random data. The variables are
    initialized by the function as it runs. It would be more accurate for
    gdb to say that the variable's value is not available before it has
    been initialized, but the gc compiler does not generate debug info
    that is sufficiently accurate for gdb to say that. So instead gdb
    displays whatever random values happen to be there.
    I would have expected the variables that are not initialized not to be
    there, that's true, it makes sense.

    why does the 'd' variable looks like that? While I could understand it
    before initialization, even if it should be 0 sized but maybe the answer is
    related to the above question, after the initialization shouldn't it be
    limited to only three values? I've tried with something like "var d [6]int"
    but then the number of elements goes down and it looks like this: "d =
    {4715168, 100, 140737353895984, 140737353895936, 0, 100, 4316562, 16,
    4816160, 0, 4461078, 4816160, 833492132160, 0, 100, 833492132160, 4409578,
    4979056, 29, 140737353932416, 833492132160, 65, 4286192, 4198466, 4272079,
    5651336, 0, 0, 4271792, 4294967296, -1, 0, 5651296, 0, 0, 4281584, 0
    <repeats 61 times>}"
    I don't know. It looks like a bug either in the gc compiler or in the
    gdb Go support or in gdb proper.
    I've did a couple of tests on this one, it seems that as long as the value
    is smaller than 129 the length of that array will be variable, depending on
    the number, so far I've got 97 and another value plus 129 (which seems to
    be more frequent as long as the size is above 10).
    It also seems that if I change the type of the elements from int to string
    the cap is 65, float32 the cap is 65, float64 cap is 225, a struct with one
    public int field and one public string field 65 and so on.

    Should I file a bug on this one or how should I proceed about it?

    why does "%v" produces a different output that "%f". According to the
    documentation: "%v the value in a default format." so shouldn't the output
    in this case be the one that "%f" produces?
    The default format for a float64 value happens to be %g, not %f.
    Also, I've forgot to ask, why is there a difference in how b and e are
    allocated / represented?

    Read http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html .
    Ian
    Thanks! Very good read.


    Again, thank you for your time in replying to this.


    Kind regards,
    Florin

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jan 17, 2014 at 1:49 am

    On Thu, Jan 16, 2014 at 3:36 PM, Florin Patan wrote:
    why does the 'd' variable looks like that? While I could understand it
    before initialization, even if it should be 0 sized but maybe the answer
    is
    related to the above question, after the initialization shouldn't it be
    limited to only three values? I've tried with something like "var d
    [6]int"
    but then the number of elements goes down and it looks like this: "d =
    {4715168, 100, 140737353895984, 140737353895936, 0, 100, 4316562, 16,
    4816160, 0, 4461078, 4816160, 833492132160, 0, 100, 833492132160,
    4409578,
    4979056, 29, 140737353932416, 833492132160, 65, 4286192, 4198466,
    4272079,
    5651336, 0, 0, 4271792, 4294967296, -1, 0, 5651296, 0, 0, 4281584, 0
    <repeats 61 times>}"
    I don't know. It looks like a bug either in the gc compiler or in the
    gdb Go support or in gdb proper.
    I've did a couple of tests on this one, it seems that as long as the value
    is smaller than 129 the length of that array will be variable, depending on
    the number, so far I've got 97 and another value plus 129 (which seems to be
    more frequent as long as the size is above 10).
    It also seems that if I change the type of the elements from int to string
    the cap is 65, float32 the cap is 65, float64 cap is 225, a struct with one
    public int field and one public string field 65 and so on.

    Should I file a bug on this one or how should I proceed about it?
    Sure, file an issue on that. Thanks. http://golang.org/issue/new

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 16, '14 at 9:27p
activeJan 17, '14 at 1:49a
posts5
users2
websitegolang.org

2 users in discussion

Florin Patan: 3 posts Ian Lance Taylor: 2 posts

People

Translate

site design / logo © 2022 Grokbase