Bug 1368188

Created attachment 1191909 [details]
File: backtrace

Created attachment 1191910 [details]
File: cgroup

Created attachment 1191911 [details]
File: core_backtrace

Created attachment 1191912 [details]
File: dso_list

Created attachment 1191913 [details]
File: environ

Created attachment 1191914 [details]
File: exploitable

Created attachment 1191915 [details]
File: limits

Created attachment 1191916 [details]
File: maps

Created attachment 1191917 [details]
File: mountinfo

Created attachment 1191918 [details]
File: namespaces

Created attachment 1191919 [details]
File: open_fds

Created attachment 1191920 [details]
File: proc_pid_status

Created attachment 1191921 [details]
File: var_log_messages

Also reproducible using:
stap --unprivileged --ldd -o "some-file.log" -c "echo 'hi'" --rlimit-as=0 dunfell-record.stp

If I remove the --rlimit-as=0, I get:

> Using a compile server.
> std::bad_alloc
> Passes: via server failed.  Try again with another '-v' option.
> For users with the privilege level stapusr, the module created by compiling your script must be signed by a trusted systemtap compile-server.  [man stap-server]
> --use-server was automatically selected in order to request compilation by a compile-server.

The --rlimit-as=XXX value is for imposing emergency resource limits on the stap-related programs.  An outright crash for a minuscule limit such as =0 is not unexpected.

(In reply to Philip Withnall from comment #14)
> Also reproducible using:
> stap --unprivileged --ldd -o "some-file.log" -c "echo 'hi'" --rlimit-as=0
> dunfell-record.stp
> 
> If I remove the --rlimit-as=0, I get:
> 
> > Using a compile server.
> > std::bad_alloc
> > Passes: via server failed.  Try again with another '-v' option.
> > For users with the privilege level stapusr, the module created by compiling your script must be signed by a trusted systemtap compile-server.  [man stap-server]
> > --use-server was automatically selected in order to request compilation by a compile-server.

What are you really trying to do here? Because you used '--unprivileged', you are running as 'stapusr', the lowest level of privilege. Those users can only run scripts "blessed" by a user with higher privilege and only probe their own processes.

Is that what you intended?

Perhaps you should join #systemtap on freenode or send an email to systemtap and we can start a conversation about how to go about what you are trying to accomplish.

(In reply to Philip Withnall from comment #14)
> Also reproducible using:
> stap --unprivileged --ldd -o "some-file.log" -c "echo 'hi'" --rlimit-as=0
> dunfell-record.stp
> 
> If I remove the --rlimit-as=0, I get:
> 
> > Using a compile server.
> > std::bad_alloc
> [...]

Ah, sorry, I missed this part.  The compile server probably has default rlimits that, if too small, could result in that std::bad_alloc.  Your stp script is not quite idiomatic (as small as possible), but also well within the range what defaults should be able to handle.  Will reopen this bug to track analysis of why that might have happened.

(In reply to Frank Ch. Eigler from comment #15)
> The --rlimit-as=XXX value is for imposing emergency resource limits on the
> stap-related programs.  An outright crash for a minuscule limit such as =0
> is not unexpected.

Ah, I misread `man stap` then, and assumed that --rlimit-as=0 imposed no limit, rather than a limit of zero.

However, running with --rlimit-as= (and no argument to it) gives another crash.

(In reply to Philip Withnall from comment #18)
> (In reply to Frank Ch. Eigler from comment #15)
> > The --rlimit-as=XXX value is for imposing emergency resource limits on the
> > stap-related programs.  An outright crash for a minuscule limit such as =0
> > is not unexpected.
> 
> Ah, I misread `man stap` then, and assumed that --rlimit-as=0 imposed no
> limit, rather than a limit of zero.
> 
> However, running with --rlimit-as= (and no argument to it) gives another
> crash.

I don't think you did misread the man page:

       --rlimit-as=NUM
              Specify the maximum size of the process's  virtual  memory  (ad‐
              dress  space),  in bytes. If nothing is specified, no limits are
              imposed.

Perhaps we should also treat '--rlimit-as=0' as '--rlimit-as=' (i.e. no limits imposed).

Commit cc72c6a updates the handling of the '--rlimit-*' options by requiring a value and giving a better error if the numeric conversion of the value fails. The man page was updated to remove that misleading "If nothing is specified, no limits are imposed." sentence.

In addition, Philip joined #systemtap on freenode and we figured out that his server '--rlimit-as' value in /var/lib/stap-server/.systemtap/rc wasn't big enough. After doubling it, everything works correctly.

So, I'm closing this one.