Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Crash in Generated Program #791

Open
jcburley opened this issue Aug 29, 2018 · 8 comments
Open

Tracking Crash in Generated Program #791

jcburley opened this issue Aug 29, 2018 · 8 comments

Comments

@jcburley
Copy link
Contributor

Though I've completed the task I originally set out to perform, I spent a fair amount of time last night trying to track down a crash in lisp-zero-go, generated from [lisp-zero-single.c](https://github.com/jcburley/LispZero/blob/master/lisp-zero-single.c, that does not happen when the .c program is run on the same test input.

I'm tracking this issue here, because it's not yet clear to me this is a c2go bug:

jcburley/lisp-zero-go#1

(But it might be....)

@jcburley
Copy link
Contributor Author

Note that I've Deferred that work for now, but if anyone wants to try to track down what could actually be a bug in the C code that is (so far) exposed only by transpiling it to Go and running the result, feel free to ask me for help with what the code is trying to do, repro steps, etc.

@jcburley
Copy link
Contributor Author

jcburley commented Sep 1, 2018

Iteratively hand-converting the generated code has hidden or fixed the issue, as of this commit:

jcburley/LispZeroGo@0f1fe73

I think it's likely the problem was due to unsafe pointers being hidden from GC, leading to re-use of in-use memory.

I'm not sure whether that's something that could be "solved" by improvements to c2go, so I'll leave this open for someone else to take up or perhaps close as "out of scope" or similar.

@elliotchance
Copy link
Owner

That's impressive you got it to work!

@jcburley
Copy link
Contributor Author

jcburley commented Sep 7, 2018

The crashes have returned (but only when profiling):

jcburley/lisp-zero-go#1 (comment)

@jcburley
Copy link
Contributor Author

jcburley commented Sep 8, 2018

This commit seems to have completely eliminated all crashes, though they seemed to go away earlier, as I was experiencing some confusion while getting used to how building and installing worked in Go, and discovered I was (often) testing versions of executables older than code with recent fixes:

jcburley/LispZeroGo@ee50b15

Note the elimination of unsafe and casting-only map.

Performance is now roughly on par with https://github.com/jcburley/LispZero/blob/master/lisp-zero-single.c, easily within an Order of Magnitude (OoM) of CPU. Color me impressed (with Go itself as well as with c2go, which greatly helped me get to this point)!

@jcburley
Copy link
Contributor Author

jcburley commented Sep 8, 2018

FWIW, I wrote a Wiki page on my performance analysis here:

https://github.com/jcburley/LispZeroGo/wiki/Performance-of-LispZeroGo-vs-LispZero-(C)

Enjoy, and thanks again for all the help!

@jcburley
Copy link
Contributor Author

jcburley commented Sep 8, 2018

Also note the new issue I created on eliminating casting-only map, which is likely only a performance, not correctness, issue:

#795

@elliotchance
Copy link
Owner

Thanks @jcburley !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants