This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ERROR: MAXACTION exceeded


"Peter Teoh" <htmldeveloper@gmail.com> writes:

> My dmesg shown below:
>  [<c0635bf0>] ? mutex_lock+0x1d/0x2d
>  [<c06357ec>] ? wait_for_completion+0x12/0x14
>  [<c043f21c>] ? put_online_cpus+0x54/0x56
>  [<c0448a6d>] ? stop_machine_run+0x31/0x38
>  [<c04423f6>] sys_delete_module+0x141/0x1ab

Interesting.


>[...]
> ERROR: MAXACTION exceeded near identifier 'probefunc' at
> /usr/local/share/systemtap/tapset/context.stp:90:10
> WARNING: Number of errors: 1, skipped probes: 16
>
> The script is just:
>
> probe kernel.function("*@arch/x86/kernel/process_32.c").call {
>         printf ("%s -> %s\n", thread_indent(1), probefunc())
>         print_backtrace();
>         printf("\n");
> }
> probe kernel.function("*@arch/x86/kernel/process_32.c").return {
>         printf ("%s <- %s\n", thread_indent(-1), probefunc())
>         printf("\n");
> }

This has no business triggering the MAXACTION limits.  That counts
script-level statements being executed, and you have just a small
handful here.  Something wacky is going on here, like
unintended/undetected reentrancy?

> And the solution is (from year 2005 email):
> Try to reset MAXACTION once in a while with this [...]

Golly, no, that's obsolete advice, and it was only for script code
that had long reporting loops in it.

> a.   from the kernel C module autogenerated, I saw that MAXACTION is
> just to prevent overrecursion, or too many loops - correct?

Roughly.  It counts statements, whether in recursed functions, loops,
or just plain inline.

> b.   under what condition are the above usable?  ie, no serious
> problem will arise?

There should be no problems with the limits are exceeded.  The probe
should cleanly shut down.

> c.   why not just eliminate the MAXACTION detection altogether, if it
> persistently give error display, but really nothing serious?

Because undetected infinite script-level loops could hang the kernel.

> d.   deadlock problem (as implied from the dmesg display above) -
> where is it and how to solve it?  is it userpsace type or system
> level?  how to find out?

Userspace level deadlocks don't show up in dmesg.  It seems as if
staprun's attempt to unload the systemtap module has hung for some
reason.  Do more "-vvv" flags produce some useful systemtap runtime
messages about the shutdown process?


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]