# Bug in nested profiling section outputs? **URL:** \ **Category:** Using preCICE\ **Tags:** cli, profiling\ **Created:** [October 29, 2025, 10:52am UTC](https://precice.discourse.group/t/bug-in-nested-profiling-section-outputs/2654 "2025-10-29T10:52:06Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ErwinM](https://avatars.discourse-cdn.com/v4/letter/e/c4cdca/32.png) [@ErwinM](https://precice.discourse.group/u/ErwinM)\ **Post date:** [October 29, 2025, 10:52am UTC](https://precice.discourse.group/t/bug-in-nested-profiling-section-outputs/2654/1 "2025-10-29T10:52:06Z")
I have been playing around with profiling in my application, and I ran into the following issue. Whenever I created nested profiling sections, the output looks like this: > N31:master\_step > B31:594768 > N32:run\_my\_step > B32:598006 > E31:598006 > E32:4035642 > E31:4053910 This is wrong! As soon as the call to start the ‘run\_my\_step’ section is handled, it immediately writes the E31 line as well, which looks to be wrong. The actual end is called and written correctly later on. The precice-cli tool fails to merge these logs, complaining about improperly nested events. When I manually remove the first E31 line, it processes properly and the output looks okay. Am I correct this is a bug? Has anyone else noticed this? This seems a very basic functionality and I haven’t seen any reports about it anywhere. ---
**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\ **Post date:** [October 30, 2025, 9:48am UTC](https://precice.discourse.group/t/bug-in-nested-profiling-section-outputs/2654/2 "2025-10-30T09:48:08Z")
Hi @ErwinM, I don’t know if this is already considered, but it is definitely good to have such feedback, especially since the profiling tools are rather new and so far mostly internally used. I would suggest directly opening an issue: [GitHub - precice/profiling: Python tools for processing preCICE profiling data](https://github.com/precice/profiling) ---
**Author:** ![fsimonis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/fsimonis/32/6_2.png) [@fsimonis](https://precice.discourse.group/u/fsimonis)\ **Post date:** [November 4, 2025, 4:18pm UTC](https://precice.discourse.group/t/bug-in-nested-profiling-section-outputs/2654/3 "2025-11-04T16:18:29Z")
> [@ErwinM](#): > > Am I correct this is a bug? Hi, I just had time to look into this. Thanks for mentioning this! This is indeed a bug when nesting user defined profiling sections. Technical reason is that vector destructs elements when increasing capacity from 1 to 2, which emits the E sections. [On godbolt](https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:17,positionColumn:2,positionLineNumber:17,selectionStartColumn:2,selectionStartLineNumber:17,startColumn:2,startLineNumber:17),source:'%23include%3Cprint%3E%0A%23include%3Cvector%3E%0A%0Astruct+S+%7B%0A++++S()+%7B+std::println(%22C%22)%3B+%7D%0A++++~S()+%7B+std::println(%22++D%22)%3B+%7D%0A%7D%3B%0A%0Aint+main()+%7B%0A%0A++++std::vector%3CS%3E+v%3B%0A++++for+(int+i+%3D+0%3B+i+%3C+4%3B+%2B%2Bi)+%7B%0A++++std::println(%22cap+%7B%7D%22,+v.capacity())%3B%0A+++++v.emplace_back()%3B++%0A++++std::println(%22---%22)%3B+%0A++++%7D%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:33.333333333333336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:g142,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'0',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'--std%3Dc%2B%2B23',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x86-64+gcc+14.2+(Editor+%231)',t:'0')),k:33.333333333333336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x86-64+gcc+14.2',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+gcc+14.2+(Compiler+%231)',t:'0')),k:33.33333333333333,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4) The fix is to change the type of `_userEvents` to `std::deque`. I’ll open a PR and link it here. ---
**Author:** ![fsimonis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/fsimonis/32/6_2.png) [@fsimonis](https://precice.discourse.group/u/fsimonis)\ **Post date:** [November 6, 2025, 1:58pm UTC](https://precice.discourse.group/t/bug-in-nested-profiling-section-outputs/2654/4 "2025-11-06T13:58:05Z")
I just merged the fix. > > > \## Main changes of this PR > > This PR fixes the bug where using nested events le…ads to extra end event entries in the profiling files. > > > \## Motivation and additional information > > The cpp solverdummy now use nested events and the validation script now checks for consistency. > > Closes #2392 > > \## Author's checklist > > \* \[x\] I used the \[\`pre-commit\` hook\](https://precice.org/dev-docs-dev-tooling.html#setting-up-pre-commit) to prevent dirty commits and used \`pre-commit run --all\` to format old commits. > \* \[x\] I added a changelog file with \`make changelog\` if there are user-observable changes since the last release. > \* \[x\] I added a test to cover the proposed changes in our test suite. > \* \[\] For breaking changes: I documented the changes in the appropriate \[porting guide\](https://precice.org/couple-your-code-porting-overview.html). > \* \[\] I stuck to C++17 features. > \* \[\] I stuck to CMake version 3.22.1. > \* \[\] I squashed / am about to squash all commits that should be seen as one. > \* \[\] I ran the systemtests by adding the label \`trigger-system-tests\` (may be skipped if minor change) ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/precice/original/1X/67d2a5fa6f80e597e2267ff17fa8c1673cd11caa.svg) [@system](https://precice.discourse.group/u/system)\ **Post date:** [November 9, 2025, 1:58pm UTC](https://precice.discourse.group/t/bug-in-nested-profiling-section-outputs/2654/5 "2025-11-09T13:58:28Z")
Closed on November 9, 2025, 1:58pm UTC This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.