Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
reflect: Call through autogenerated method corrupts memory on ppc64le #10628
Comments
davecheney
added
the
OS-Linux
label
Apr 30, 2015
davecheney
added this to the Go1.5 milestone
Apr 30, 2015
|
Stupid question, but something about 0xf8010260f8010260 certainly catches the eye. Is 0xf8010260 a valid pointer? (It doesn't disassemble to anything very remarkable, ori r2,r0,504 or std r0,8288(r1) depending on endianess) |
|
Oh, I didn't spot that the top and bottom words are duplicated.
|
|
Same as #10844 ? |
|
@rsc I'd hope so, but I cannot confirm at this time. I spent all yesterday bisecting trying to find a revision that this problem didn't exist in. The annoying part of that is that while I can replicate this problem easily at tip, as I go back in time the problem is still there, just less frequent so confirming a revision is good involves testing multiple times at each revision. I hope to have the bisecting done today. |
|
I don't believe this is the same as 10844 anymore. |
|
There were some bugs in reflect.Call's type bitmaps that I fixed in May. |
rsc
changed the title from
cmd/gc: reflect.Call through autogenerated method corrupts memory on ppc64le
to
reflect: Call through autogenerated method corrupts memory on ppc64le
Jun 8, 2015
|
I'll test again. I may be able to get you access to this system, but that On Mon, 8 Jun 2015 16:07 Russ Cox notifications@github.com wrote:
|
|
@rsc it looks like the problem is still there. It takes more load on the machine to trigger it, but it still happens. Because of $BUREAUCRACY I probably cannot get you access to the machine. I'll try to come up with a reproducer. |
|
We're going to push ppc64 work off to Go 1.6 at this point. |
rsc
modified the milestones:
Go1.6,
Go1.5
Jul 21, 2015
|
I turned of gocheck's pretty printing of the panic backtrace and found something interesting It looks like the autogenerated method is not directly responsible (although adding an explicit forwarding method rather than letting the kernel generate the wrapper always fixes the crash)
|
davecheney
closed this
Aug 11, 2015
pushed a commit
to davecheney/juju
that referenced
this issue
Aug 12, 2015
davecheney
referenced this issue
in juju/juju
Aug 12, 2015
Merged
Undo workaround for golang/go#10628 #2968
added a commit
to juju/juju
that referenced
this issue
Aug 12, 2015
davecheney commentedApr 30, 2015
I'm very sorry about the quality of this issue report, I've yet to be able to resolve it to a smaller reproduction.
The background is we have an API server which instruments types and exposes their methods over an RPC interface. This stack trace is from the sever side, attempting to dispatch to
agent.(*AgentAPIV1).StateServingInfohowever
AgentAPIV1is defined asSo the compiler has autogenerated
AgentAPIV1.StateServingInfoand forwarded it toAgentAPIV0.StateServingInfoHowever, looking at the receiver value for
agent.(*AgentAPIV1).StateServingInfoit is0x00, but in the next frame the receiver is0x31f5c8, this may be related to the problem.The faulting line, /home/ubuntu/src/github.com/juju/juju/apiserver/agent/agent_v0.go:93, is
and at this point the value of
authis garbage, its interface type and value are random junk,runtime.convI2E(0xf8010260f8010258, 0x7c030378e8410070, 0x0, 0x0)So far I have been able to determine that manually adding the forwarding method
Stops the panic, but I have not yet been able to construct a stand alone reproduction.
Sadly this only happens on our ppc64le system, which is not accessible to others.
/cc @randall77 @minux @aclements