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

runtime: ebpf uprobe support #22008

Open
shashankmjain opened this Issue Sep 25, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@shashankmjain

shashankmjain commented Sep 25, 2017

We had issue with using uprobes with ebpf due to dynamic nature of golang stacks. Is there a proposal/way to address that?

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 25, 2017

What is ebpf? What are uprobes?

The Go compiler is committed to having stacks that grow, and therefore move, as needed. That is a key part of supporting programs that use a very large number of goroutines.

@shashankmjain

This comment has been minimized.

shashankmjain commented Sep 25, 2017

ebpf is the linux tracing mechanism and uprobes are dynamic probes for user space programs. The ebpf program attaches to a user probe and gets executed when that function is invoked. Here it seems the golang stack is resized and the return of the ebpf program gets a segmentation fault as it points to a invalid address

@cznic

This comment has been minimized.

Contributor

cznic commented Sep 25, 2017

Sounds like ebpf/uprobes supports only processes having a pure C ABI with thread-static stacks .

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 25, 2017

I don't see how we could support a dynamic probe executed by the kernel that refers to a local address on the stack.

@ianlancetaylor ianlancetaylor changed the title from ebpf uprobe support to runtime: ebpf uprobe support Sep 25, 2017

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Sep 25, 2017

@brendangregg

This comment has been minimized.

brendangregg commented Sep 25, 2017

Anyway for go to pause the moving of stacks, eg, by sending it a signal? That way the behavior could be disabled temporarily while the kernel did user-level instrumentation.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 25, 2017

The SIGSTOP signal would work.

There is no way to disable moving stacks other than stopping the program, though. There can't be: program execution could require additional stack space at any time.

@gianlucaborello

This comment has been minimized.

gianlucaborello commented Jul 25, 2018

FYI I posted a tentative solution that I'm experimenting with to work around this problem, and would appreciate comments and skepticisms: iovisor/bcc#1320 (comment)

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment