Debug multithread code

[Michael Lee]

Hi,

I find it's difficult to debug multithread code on a multiple-core computer. Sometimes it does not step into a function (I'm using vscode + wsl). Does deal.II use all the cores available? For the sake of debug, how can I limit the cores used? Is there a way to debug the code just like series one?

Regards,

Michael

[Timo Heister]

Take a look at set_thread_limit:

https://www.dealii.org/current/doxygen/deal.II/classMultithreadInfo.html

As you can see, you can also control it using an environment variable, so you don't have to recompile.

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/b123aaf2-8d32-4b43-b818-8d2ae9ffac77n%40googlegroups.com.

[Michael Li]

I put MultithreadInfo::set_thread_limit(1) in main function, but still cannot do step debug in the function

assemble_neumann_contribution_one_cell. Am I doing something wrong?

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAMRj59HvBtTTF1D3SnGHgbnub4nNN_6TC0aYPqHJRK3NYoqdVA%40mail.gmail.com.

 

[Timo Heister]

What do you mean by "cannot do step debug"? Are you compiling in debug mode?

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/B6A6B8CA-9E60-4912-BC84-5706D0E86574%40hxcore.ol.

[Michael Lee]

Yes, I'm in debug mode. I mean I cannot step over one line each time or step into a function. I have to set a lot of breakpoints to stop the program at these lines.

On Aug 5, 2021, at 6:16 PM, Timo Heister <hei...@clemson.edu> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAMRj59G5y%3DjGV%3DnOEUrnDtMNy6F9RoU%3D5c4RGs7HJS%3DcjQDLTA%40mail.gmail.com.

[Timo Heister]

It sounds like (I don't know what code you are running) that you use something like WorkStream::run or mesh_loop that calls your assemble function.

Stepping into this function should be possible (assuming you have deal.II installed in a way that gdb can find the source code). What happens if you step into it?

Of course this is a more complicated situation than a simple step-3 assembly loop. I would probably add a breakpoint inside the function of interest...

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/53D60D09-BAD7-4F13-96EB-9AE7016E5A23%40gmail.com.

[Michael Li]

Hi Timo,

Yes. I’m running code using WorkStream::run looking like the following.

    void

    assemble_system_one_cell(const typename DoFHandler<dim>::active_cell_iterator &cell,

                             ScratchData_ASM &scratch,

                             PerTaskData_ASM &data)

    {

1. assemble_system_tangent_residual_one_cell(cell, scratch, data);

2. assemble_neumann_contribution_one_cell(cell, scratch, data);

    (3)}

 

I set a breakpoint at line (1), then press F10 in VSCode to proceed to line (2), but it keeps pausing at line (1). As you suggested, I put another breakpoint at line(2), now it stops at line (2) as expected when I press F10 when it pauses at line (2). The only inconvenience is that I have to set a breakpoint where I want it to stop.  I can also step into the function in line (1) by pressing F11 and even come to the source code of run() function in work_stream.h.

 

Here is a snapshot shows the debug state and all the threads are shown in the left panel.

 

 

There is an annoying window keeps popping up during the debugging. Any hint to get rid of that?

 

 

Thank you for you help!

 

Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAMRj59FLH%3Dz%3DvGxfYQYk6EcHfOjrQG%3D627M1t2TNovHj3%3DKGBw%40mail.gmail.com.