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]

[Bug runtime/20279] in parallel testsuite mode, we're getting SIGSEGVs


https://sourceware.org/bugzilla/show_bug.cgi?id=20279

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|in parallel testsuite mode, |in parallel testsuite mode,
                   |we're getting SIGABORTs     |we're getting SIGSEGVs

--- Comment #3 from David Smith <dsmith at redhat dot com> ---
(In reply to Josh Stone from comment #2)
> FWIW, signal 11 is SIGSEGV.

Sigh. That's what I get for relying on my memory.

> I do seem to recall that the rlimit test triggers these on purpose.  I would
> not expect that to affect others tests running in parallel though.

When I run the rlimit.exp test by itself, I don't see any of those messages on
the console. That test will involve stap calling getrlimit/setrlimit, but that
should only affect that particular stap pid (and its descendants), not other
previous or future stap processes.

There is another test, bad-code.exp, that purposely sends a SIGSEGV, but when
that test is run I don't see the message on the console.

I need to poke around in the kernel and see why it prints these messages - why
these SIGSGVs are different than regular SIGSEGVs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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