These are chat archives for derekparker/delve

4th
Mar 2016
Evan Digby
@evandigby
Mar 04 2016 00:20 UTC
Confirmed it's happening on OSX only. My linux box, same source runs without issue. Go 1.6 on OS X 10.11.. Will continue to try to repro and make a proper bug report
Alessandro Arzilli
@aarzilli
Mar 04 2016 06:34 UTC
@evandigby others had different problems with maps on OS X: derekparker/delve#302
Evan Digby
@evandigby
Mar 04 2016 07:34 UTC
@aarzilli Interesting, also on "init" (my issue is happening during init for google's proto package). I still haven't been able to reproduce it in a toy sample.
Alessandro Arzilli
@aarzilli
Mar 04 2016 07:38 UTC
does it happen every time or just sometimes?
if it happens every time does it happen every time in the exact same way?
Evan Digby
@evandigby
Mar 04 2016 15:27 UTC
@aarzilli every time, exactly the same way. If I step through to that point it always comes in the same order and all values in t.hmap are always zero
Alessandro Arzilli
@aarzilli
Mar 04 2016 15:49 UTC
@evandigby could you possibly disassemble for me the function that makes the call to runtime.makemap that eventually panics?
disass -l <name of the function>
Evan Digby
@evandigby
Mar 04 2016 16:34 UTC
@aarzilli I spoke to soon. Some minor changes to the source and now it's happening (same bug) in a different spot, for a different makemap. I will attempt to disassemble them both
All in init
Evan Digby
@evandigby
Mar 04 2016 17:02 UTC
Sorry, there was some confusion because it's happening in non-existent init functions.
The disassembly is quite long, where should I put it? I'm new to Gitter
Evan Digby
@evandigby
Mar 04 2016 17:08 UTC
comes from message_set.go:274:
var messageSetMap = make(map[int32]messageSetDesc)
Would it be valuable to compare that to a disassembly of the same code compiled for linux and working? (this is OSX as I mentioned). Same architecture (running in virtualbox on same machine)
Evan Digby
@evandigby
Mar 04 2016 17:27 UTC
This might be more useful, an end-to-end debugging session to get us there:
http://pastebin.com/YjPrFPRR
Alessandro Arzilli
@aarzilli
Mar 04 2016 17:33 UTC
@evandigby: thank you very much
as you can see runtime.makemap gets its first parameter from a static address [rip+0x534966]
so either we are overwriting memory (which I don't think it's possible) or we are interfering with the loader somehow
didn't even know it was possible
Evan Digby
@evandigby
Mar 04 2016 17:38 UTC
It's worth noting that it periodically gets a similar bug elsewhere, also in runtime (time/format.go), but when that one occurs the t.hmap memory is totally corrupt ("unreadable"), but t is still readable
Evan Digby
@evandigby
Mar 04 2016 17:43 UTC
In a toy sample I force the proto package (where message_set.go belongs) to import, but in that case it works