-
Notifications
You must be signed in to change notification settings - Fork 237
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
Support syscalls necessary for Go runtime #1540
Comments
Also thank you so much for all this awesome Shadow work, I'm really excited about this project! |
Also, fwiw it might be that
|
The place to check for syscall support in Shadow would be in the syscall handler switch statement: shadow/src/main/host/syscall_handler.c Lines 270 to 511 in 9cea24a
The |
For I just pushed robgjansen@1a1c7ea, an untested, quick-and-dirty example of adding a |
Thanks! I just tried it out and it was enough to get things working. I'll try running some experiments with this and see what happens :) |
I'm getting stuck again. I made a minimal Go server example and I'm seeing the same behaviour there: https://github.com/cohosh/go-shadow This is the output I get with Rob's patch for It looks like it's either the result of the unsupported |
Is a CPU core taxed at 100% during the stall, indicating a spin-loop? Otherwise, my guess is that the signaling part of |
Yup it's spinning at 100%. |
Hmm, I don't like spin loops :( I'm guessing it's making that There are some ways we could handle infinite loops, none of them are very nice from a design standpoint. In this case, we would probably need to hook the |
Here's part of an strace of the server after one curl client, then stopped with SIGINT. I don't see anything related to sched_yield here, but there's a lot of IPv6 and signal stuff that we don't support.
I think we can get rid of the ipv6-related errors using: server := &http.Server{Handler: handler}
l, err := net.Listen("tcp4", ":80")
if err != nil {
log.Fatal(err)
}
err = server.Serve(l)
Oops ignore me, was running with the unpatched version by accident. Edit: When running with rob's patched version, shadow gets stuck, and a backtace of the server process says the following (blocking on
|
@robgjansen: The issue seems to be a problem with shadow's epoll. Shadow is getting stuck at:
Time doesn't seem to advance, and it seems that there are items in the ready table that aren't actually ready. I replaced guint epoll_getNumReadyEvents(Epoll* epoll) {
MAGIC_ASSERT(epoll);
GHashTableIter iter;
g_hash_table_iter_init(&iter, epoll->ready);
gpointer key;
gpointer val;
while (g_hash_table_iter_next(&iter, (gpointer) &key, (gpointer) &val)) {
EpollWatch* watch = val;
if (!_epollwatch_isReady(watch)) {
g_hash_table_iter_remove(&iter);
}
}
return g_hash_table_size(epoll->ready);
} And shadow no longer gets stuck, and we successfully see |
@cohosh If you try the Go server in Shadow it should work now. There are still unsupported syscalls (mainly IPv6 and signal related), but the curl client is able to successfully make requests to the server. If you run into any issues running other Go programs, please let us know. |
Ah thank you! I'll give it a try today. |
I just tried running the go minimal example (with your modifications to prevent the IPv6 errors), it's not terminating, and I'm not getting any successful stdout or stderr for either the client or server, and the shadow.log is getting spammed with these messages:
|
Oops sorry, I should have tested in release mode as well. I have a fix at #1553, which should be merged later today. |
Okay awesome, the simple Go server is working for me now! I'll try the snowflake experiments again :) |
Closing based on this comment in #1558 from @cohosh:
|
Describe the issue
I'm working on getting Snowflake simulations running in Shadow, and for all of the Go binaries I'm running up against the same unsupported system calls. Here's an example from the broker:
The unsupported system calls are:
sched_getaffinity (204)
epoll_pwait (281)
It's also throwing an
ENOSYS
error forsched_yield (24)
which is strange because AFAICT from looking at the source code, it's implemented.Since these are being called from the Go runtime library and I've tried setting
GOMAXPROCS=1
with no success, I suspect they are necessary for all Go programs (or at least all that have any goroutines).To Reproduce
Try running any Go program with goroutines
Shadow (please complete the following information):
Shadow 2.0.0-pre.4
The text was updated successfully, but these errors were encountered: