- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The app I'm working on has thread issues when I switch from GCC 5.3 to GCC 11.2.
I'm running some tests with Inspector 2018 (I know that is old, but I work for a large multinational and requesting an upgrade is likely to take many months). This is on a Xeon 6226R, RHEL Linux 7.9. We use MKL and Intel OpenMP, which is why I'm using Inspector. I'm using GCC 11.2 and using a debug build - GDB has no problem reading the debug symbols.
Our app has a rather complicated setup script to launch it, but basically I ran "inspxe-cl -collect ti3 -- " and then my app and its arguments.
I have about 100 errors detected. Our app uses OpenMP for threading.
The first problem is that a small number of errors are in a shared library that we generate and load on the fly. I'm looking into haw that is handled - I'm not sure if that is built with debug info as it gets deleted on exit.
I don't know yet if it will help, but does Inspector have an option similar to Valgrind that does this:
--keep-debuginfo=no|yes Keep symbols etc for unloaded code [no]
This allows saved stack traces (e.g. memory leaks)
to include file/line info for code that has been dlclose'd (or similar)
I don't see any source code for the main application either. All I get is some function names in the Summary pane (like application!functionName)
I have been able to get to the source code by
- loading the exe in gdb
- Using disas /s with the function names that are shown
This is very tedious and I don't want to do it hundreds of times.
EDIT:
It seems to work OK with GCC 5.3.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thank you for posting in Intel communities.
Could you please try the below suggestions to get the line numbers to identify the location of source code?
1. gcc -fopenmp <program> -g -o <exe>
2. inspxe-cl -r my_result -collect ti3 -- ./<exe>
3. inspxe-cl -report problems -result-dir my_result/
Please find the attachment that shows on which line the errors are present.
Note that if symbol information and source are not available, all problems still will be reported. But there is no line No. info (use module's offset instead) in "Source" of "Code Locations" of the report, also you can't do "View Source".
If the given suggestions resolve your issue, make sure to accept this as a solution. This would help others with similar issue.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm running some more tests which are quite long. Will update shortly (hopefully tomorrow).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the update.
Please let us know once you finish with your tests.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried again. Firstly I made a change so that the C file and shared object that gets generated, build and dlopened does not get removed. I can now see the source code in the Inspector gui for this file.
However, I still get nothing for the main executable.
I am _not_ linking as you suggest (which I believe is incorrect). Unfortunately, as I understand it, GCC has no option to use it as the linker driver and use a non-GCC version of the OpenMP library. There are two ways to get around this
One is to not link with -fopenmp and to link explicitly with libiomp5.so
The second is to link with -fopenmp and libiomp5.so but also to link with -Wl,--as-needed, which is what we do. Personally I think the first option is better since as-needed could be hiding link errors.
I don't see any errors in libgomp.so.1
There are a few errors in a third party shared library which doesn't have debuginfo. So as expected that doesn't have source information.
I tried downloading Inspector 2023.1 and that looks like it works OK. I'll run a few more tests, but it looks like this thread can be closed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Glad that you upgraded to the latest version and it's working fine, and thanks for providing your possible workarounds to the community.
In our previous reply our suggestion was to use -g as an option so that you can find source information while analysis with inspector.
As your issue got resolved, this thread will no longer be monitored by Intel. If you need further assistance, please post a new question.
Thanks
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page