[Bug libgomp/61798] New: OpenMP exit code 155, profiling related?

[Bug libgomp/61798] New: OpenMP exit code 155, profiling related?

[kessler at iag dot uni-stuttgart.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798

            Bug ID: 61798
           Summary: OpenMP exit code 155, profiling related?
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kessler at iag dot uni-stuttgart.de
                CC: jakub at gcc dot gnu.org

I have got an OpenMP program (written in C++) up and running. However, when
running my test suite of 43 cases for profiling (with -pg, it's CFD flow solver
running in batch mode), some (usually 2-3) cases fail with an exit code of 155
-after- full completion of my code (that is, after return 0; in main). This
only happens if several codes run in parallel on the same machine (this
capability of the test script is from before the OpenMP parallelisation
effort), and even then not always, and with varying cases, so I am quite
confident it is not primarily a bug in my code.
>From scanning the output I have seen a message from the shell, apparently
catching a SIGPROF, which seems reasonable as I have profiling enabled, but
probably should not propagate outside the executable. I have never seen this
problem with profiling in non-OpenMP mode.
Unfortunately I can not share my code, but I think it is not related to the
user code anyway, but perhaps some race condition in the interaction between
profiling and OpenMP at program exit?

Thanks for shedding some light on this bizarre situation.

Ciao,

    Manuel

[Bug libgomp/61798] OpenMP exit code 155, profiling related?

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Exit code 155 is indeed that the process has been killed by SIGPROF signal.
Without a testcase there is hard to say anything more on this, libgomp
certainly doesn't install a signal handler for this signal, nor generate it,
nor do anything else with it, so I bet you'd get exactly the same situation if
you just used pthread_create yourself instead of OpenMP.

[Bug libgomp/61798] OpenMP exit code 155, profiling related?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What target is this on?

[Bug libgomp/61798] OpenMP exit code 155, profiling related?

[kessler at iag dot uni-stuttgart.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798

--- Comment #3 from Manuel Kessler <kessler at iag dot uni-stuttgart.de> ---
Thank you both for trying to help.

@Andrew: This is on x86_64, running kernel 3.1.0 on an (admittedly old)
openSUSE 11.4. 

@Jakub: You are probably right, but the question remains, how a SIGPROF
(probably from the profiling machinery added with -pg) can escape up to the
user level instead of being catched by said machinery - and what to do against
it, of course.

Ciao,
    Manuel

[Bug libgomp/61798] OpenMP exit code 155, profiling related?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The only think I can think of is somehow the signal does not get masked
correctly and/or stopped correctly before exiting. But this would be a glibc
issue as libgomp is just calling normal pthread_* functions to create and exit
the threads. libgomp does use the futex system call but that should not matter
with respect to the signal and all.