@@ 91,7 91,7 @@ The next day, it occurred to me that the Linux kernel might have more informatio
I then understood what was going on: the alignment exception was complaining about the address 0x2eb4dbb, which is 48975291 in decimal.
This number looks odd (pun intended), because a float64 is 8 bytes large, and its address should be a multiple of 8 (which 48975291 is obviously not).
-I checked again using printf() debugging and sure enough the panic only happened when the float64 was not a multiple of 8 (i.e, was misaligned).
+I checked again using printf() debugging and sure enough the panic only happened when the float64 address was not a multiple of 8 (i.e, was misaligned).
## golang digging
@@ 101,17 101,17 @@ Now that the bug was identified, I had to understand how it could be that a floa
I prepared a detailed bug report and looked around for similar issues. I quickly found another issue for a sigbus fault on ARM.
-=> https://github.com/golang/go/issues/38331 cmd/link: sigbus/segfault on ARM using AzCopy
+=> https://github.com/golang/go/issues/38331 cmd/link: sigbus/segfault on ARM using AzCopy · Issue #38331
At the end of my bug report, I added a link to this issue and wanted to add a reason why my report was different. I inspected closely the issue and saw that they were using unsafe pointers. Upon writing something like "related issue #38331: unsafe pointers are used", I thought that I should better check that my program wasn't using unsafe pointers...
## VictoriaMetrics debugging
-I then saw that the []float64 slice was being constructed using unsafe pointers! I was quite sad that I didn't find a bug in the Go compiler, but quite happy that I could solve the issue myself. Finally I adjusted the code to perform alignment adjustments in case of misalignment, and everything has been running smoothly since then!
+I then saw that the []float64 slice was being constructed using unsafe pointers! It was quite sad that I didn't find a bug in the Go compiler, but I was quite happy that I could solve the issue myself. I adjusted the code to perform alignment adjustments in case of misalignment, and everything has been running smoothly since then!
=> https://github.com/VictoriaMetrics/VictoriaMetrics/pull/3927 Pull request to fix the alignment panic in VictoriaMetrics
## Conclusion
-Next time that I debug a low-level issue, I will remember to look at the kernel messages first (dmesg). It would have spared me a lot of troubles with generating and inspected core dump (which didn't help me in the resolution).
-And be extra careful when using the unsafe package (as the name helpfully reminds).>
\ No newline at end of file
+Next time that I debug a low-level issue, I will remember to look at the kernel messages first (dmesg). It would have spared me a lot of troubles with generating and inspecting core dumps (which didn't help me in the resolution).
+And remember to be extra careful when using the unsafe package (as the name helpfully reminds).<
\ No newline at end of file