5 comments

  • dlopes7 2 hours ago
    Very interesting read, these bugs that only happen after a lot of time in production are the worse to troubleshoot
  • budman1 57 minutes ago
    Isn't this something that software developers do everyday?
    • apitman 30 minutes ago
      The way I look at these types of difficult debugging problems has completely changed.

      If it's a system I want to understand more deeply and I have the time, I try to force myself to do it by hand. If not, the agent does it.

      The trap is that it's easy to convince myself that I never have the time.

      • budman1 22 minutes ago
        Not being a user of agents, my question is 'does the agent always find the root cause and remove the defect'?

        The way I got good at finding the hard ones was finding hard ones. Without that practice, I would be helpless.

  • ReactiveJelly 2 hours ago
    So a stronger type system in the boundary between Go and Linux would have caught this?
    • fn-mote 2 hours ago
      My reading is that this is entirely Go’s fault. In Go, there was a union of two different types without metadata to distinguish the two. The disambiguation was done by looking to see if the data looked like a certain pointer.

      I think the reason it is a problem only in 32 bit systems is that the assignment setting the lower half of the data is a 32 bit op, which can overflow the 16 bits used, but won’t affect the other half of a 64 bit value. (Corrections welcome.)

  • BlackRabbit1 6 hours ago
    Not directly related to your embedded Go bug, but maybe helpful:

    What really sky-rocketed my debugging skills in embedded devices was learning to utilize the Python plugin interface of 'gdb'.

  • DarmokTanagra 6 hours ago
    I wonder what other 32 bit bugs are waiting to be discovered.