nil pointer dereference HandleCallCommon Functions.go:64 #26
Comments
|
@jtorvald first of all sorry for the inconvenience with the panics. I consider this project to be early in its development so many bugs are expected (unfortunately).
|
|
@amit-davidson I completely understand. I didn't meant to sound complaining. Just eager to test this out and provide you with the things that go wrong so you can improve it.
If you have any idea what could cause this I might be able to deduct what in my code causes this and I can maybe create a separate project for you to debug that issue. |
|
@jtorvald ohhhhh...
|
|
@amit-davidson cool! |
|
@jtorvald You can already try to use master. It should solve it for you. |
|
@amit-davidson thanks! Hereby the next issue I run into. panic: runtime error: index out of range [-1] goroutine 1 [running]: |
|
@jtorvald Wow. Actually, it surprises me. Basically, it fails since it detects a call to Lock/Unlock (Checks for this name |
|
@amit-davidson Not sure if I understand you 100%. Unlock does not have arguments right? Or that is exactly the problem... I managed to figure this out: Is there a way to do a "Stacktrace" to see where it originates? |
|
@jtorvald Mutex in a struct as a field, or even embedded works so that's not the case. I also tried to reproduce it locally by calling Wait on About seeing where it originates, that's good idea. There's no need to calculate the "entire" stacktrace to determine the flow, just to see where it's located in the code which is the You can use the function If it still doesn't work for you, I would suggest a session. (if that's something you're comfortable with of course. I don't want to push it). |
|
Hey @jtorvald, |
|
Hey @amit-davidson that is good news. I figured something out a couple of days ago and wanted to write you but haven't had the time. Life is a bit chaotic at the moment. I figured out what part of the code it comes from and tried to isolate it, but the funny thing is that if I move the code to separate main.go or to merge the code from two libraries in one with only the problem code then it doesn't happen. Exact same code, just copy and paste and removed the import. In my code it has to do with the sync.Pool and maybe an "internal" package name. But not 100% sure what causes the issue since when I move the code to a separate command it doesn't crash. It only checks code that gets in one of the code paths right? I just updated and tried the new version and the old error seems to be gone. The test program with my library now also gives no data races. So that is good news. But I got something in return: goroutine 1 [running]: It's no rush for me to figure it out, just wanted to help you find edge cases. I could do a screenshare or something if you want. Just not sure when I have the time for it. I could drop you a mail and we can see if we can find some time somewhere. |
|
@jtorvald Hope everything is fine and you are safe.
Regarding the above. The answer is yes. It inspects all paths deriving from the main functions. I'm not really sure why it stopped panicking after merging the 2 libraries but I assume the problematic code was skipped due to the reason just mentioned. I'm happy everything is ok now and the program is stable. |
|
@amit-davidson yeah, we're good, thanks! The line where it happens: |
|
The good news is: no crash... Bad news, it's frying the CPU for like 20 minutes and then I stopped it.
|
|
@jtorvald |
|
@amit-davidson yeah still the same code. Not so big code base: Some -v verbose option would maybe be helpful to see what it is doing and if it is repeating something? But probably the trick is to spit out the exact useful information... since it's probably a lot that it is doing. |
|
@jtorvald |
|
@amit-davidson cool. Let me know when I can test that! no rush ;-) |
|
Hello. We got the same issue. Any updates regarding to this trouble? |
After my first try a month ago when I had a nil pointer exception I now first I ran:
go get -u github.com/amit-davidson/Chronos/cmd/chronos
Then tried again to run the application but no luck. The issue is within a single package I think. I tried with the -pkg flag and seems that all the other packages work well including internal.
Hope this helps you:
Functions.go:64
fs := domain.CreateFunctionState(blockStateRet.GuardedAccesses, blockStateRet.Lockset)panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x146e3c4]
goroutine 1 [running]:
github.com/amit-davidson/Chronos/ssaUtils.HandleCallCommon(0xc04186c780, 0xc02ad5be08, 0x13a592c, 0x0)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/Functions.go:64 +0x774
github.com/amit-davidson/Chronos/ssaUtils.GetBlockSummary(0xc0259b9f48, 0xc02ad4c840, 0xb)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/Functions.go:160 +0x43e
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).calculateBlockStateIfNeeded(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c840)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:90 +0x75
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c840)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:33 +0xa8
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c790)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c6e0)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c630)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c420)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c4d0)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02ad4c370)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02a551ce0)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc02a551c30)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc00c0f9ce0)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc00c0f9c30)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc00c0f9b80)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).traverseGraph(0xc0259b9ce8, 0xc0259b9f48, 0xc0259b9ba8)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:41 +0x4c2
github.com/amit-davidson/Chronos/ssaUtils.(*CFG).calculateFunctionState(0xc0259b9ce8, 0xc0259b9f48, 0xc00c0f9b80)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/CFG.go:27 +0xd0
github.com/amit-davidson/Chronos/ssaUtils.HandleFunction(0xc0259b9f48, 0xc02840b040, 0xc0239a1e60)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/Functions.go:201 +0x298
github.com/amit-davidson/Chronos/ssaUtils.HandleCallCommon(0xc0259b9f48, 0xc04185ae40, 0x13a565f, 0x0)
/Users/developer/go/src/github.com/amit-davidson/Chronos/ssaUtils/Functions.go:63 +0x767
main.main()
/Users/developer/go/src/github.com/amit-davidson/Chronos/cmd/chronos/main.go:34 +0x4b9
The text was updated successfully, but these errors were encountered: