error message "management.cpp:712 (anonymous namespace)" when compiling mex with openmp
조회 수: 22 (최근 30일)
이전 댓글 표시
Hello,
I am compiling mex function with openmp using MATLAB 2019b and gcc-6.3.0.
My mex command is the following:
mex mex_count.cpp CXXFLAGS="$CXXFLAGS -fexceptions -fPIC -fno-omit-frame-pointer -pthread -std=c++11 -std=c++11 -fopenmp" -lgomp;
While mex is compiled competed successfully, I still got the following error message:
Building with 'g++'.
MEX completed successfully.
MATLAB: management.cpp:712: find: Assertion `find: no active context for type '(anonymous namespace)::AlreadyReportedFailure'' failed.
Hello World from thread 0, 0
Hello World from thread 0, 5
Hello World from thread 0, 10
MATLAB: management.cpp:712: find: Assertion `find: no active context for type '(anonymous namespace)::AlreadyReportedFailure'' failed.
The same code runs successfully using MATLAB 2017b and gcc-4.8.5. The error occurs when I move everything to google cloud platform.
Thank you,
Yangfan
댓글 수: 3
Paul Dankoski
2020년 9월 21일
편집: Paul Dankoski
2020년 9월 21일
we are not using openmp and see this error too with Matlab 2020a and GCC 6.3.0. Any insights appreciated.
Also, i see this on line 702 whereas original message above shows it on line 712.
MATLAB: management.cpp:702: find: Assertion `find: no active context for type '(anonymous namespace)::AlreadyReportedFailure'' failed.
Is management.cpp code something we can investigate?
답변 (1개)
Tim Davis
2020년 9월 27일
I had a similar problem (Linux, MATLAB 9.8.0.1396136 (R2020a) Update 3). It was a mexPrintf inside an OpenMP parallel region. I don't think mexPrintf is thread safe. I tried placing the mexPrintif in a #pragma omp critical section, but the error still occurs. Sometimes I get the detailed traceback (with mexPrintf listed in the trace) but often I will get just:
MATLAB: management.cpp:702: find: Assertion `find: no active context for type '(anonymous namespace)::AlreadyReportedFailure'' failed.
The system printf is thread-safe, but when you compile a mexFunction, but mex.h defines printf as a macro which is just mexPrintf. So you get mexPrintf instead, which then dies if used inside the parallel region.
The simplest solution is to not use printf in a parallel region. If you really need it, try undefining printf after you include mex.h. The output will not go to the MATLAB Command Window, however. Perhaps you could write it to a file if you really need to. I tend to run MATLAB with -nodesktop anyway, and both printf and mexPrintf send their output to the terminal window. The system printf output is not captured if I use the MATLAB diary command, but otherwise it works fine.
댓글 수: 1
Paul Dankoski
2021년 1월 13일
Thank you, Tim. And yes, in my case, it seems to have been related to mexPrintf in overflow() code roughly following this other mex suggestion.
참고 항목
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!