error message "management.cpp:712 (anonymous namespace)" when compiling mex with openmp
20 views (last 30 days)
Show older comments
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 Comments
Paul Dankoski
on 21 Sep 2020
Edited: Paul Dankoski
on 21 Sep 2020
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?
Answers (1)
Tim Davis
on 27 Sep 2020
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 Comment
Paul Dankoski
on 13 Jan 2021
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.
See Also
Categories
Find more on Write C Functions Callable from MATLAB (MEX Files) in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!