Finding the cause of RuntimeError: Expected to mark a variable ready only once

I’m extending a complex model (already with DistributedDataParallel with find_unused_parameters set to True) in PyTorch on detectron2.

I’ve added a new layer generating some additional output to the original network - initially, that layer was frozen (requires_grad = False) and everything was working fine. I later decided to unfreeze this layer. Unfortunately, this results in this error on multiple GPUs:

-- Process 0 terminated with the following error:
Traceback (most recent call last):
...
  File "/xxx/trainer.py", line 585, in some_method:
    losses.backward()
  File "/xxx/python3.7/site-packages/torch/tensor.py", line 221, in backward
    torch.autograd.backward(self, gradient, retain_graph, create_graph)
  File "/xxx/python3.7/site-packages/torch/autograd/__init__.py", line 132, in backward
    allow_unreachable=True)  # allow_unreachable flag

RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 
1) Use of a module parameter outside the `forward` function. Please make sure model parameters are not shared across multiple concurrent forward-backward passes
2) Reused parameters in multiple reentrant backward passes. For example, if you use multiple `checkpoint` functions to wrap the same part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases yet.

Clearly, the error is related to that unfrozen layer, since everything was working before unfreezing it. This means that I need to check every change I made.

I wonder if there’s a way/trick to determine which particular tensor/operation causes this behaviour? In other words - how can I speed up the debugging process?

Asked the same question on SO here.

RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 1) Use of a module parameter outside the forward function. Please make sure model parameters are not shared across multiple concurrent forward-backward passes 2) Reused parameters in multiple reentrant backward passes. For example, if you use multiple checkpoint functions to wrap the same part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases yet.

The runtime error reports the problem. Have you tried checking changes related to the 2 possible errors?

Also, did you use the python pdb debugger?

Yes, I tried checking all my changes - I write the post since I can’t find the cause in my code. I also tried debugging with VSCode if that matters.

Hi, can you try first setting the environment variable TORCH_DISTRIBUTED_DEBUG=INFO. If you need more detail, you can set it to TORCH_DISTRIBUTED_DEBUG=DETAIL. You will need to use nightly builds with this environment variable set.

1 Like

Thanks - it helped me to move forward. Turns out this feature is available in PyTorch 1.9.0 (was using 1.7.0), so no need to use nightly builds.

Now I have this error:

RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 1) Use of a module parameter outside the `forward` function. Please make sure model parameters are not shared across multiple concurrent forward-backward passes. or try to use _set_static_graph() as a workaround if this module graph does not change during training loop.2) Reused parameters in multiple reentrant backward passes. For example, if you use multiple `checkpoint` functions to wrap the same part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases in default. You can try to use _set_static_graph() as a workaround if your module graph does not change over iterations.
Parameter at index 73 has been marked as ready twice. This means that multiple autograd engine  hooks have fired for this particular parameter during this iteration. You can set the environment variable TORCH_DISTRIBUTED_DEBUG to either INFO or DETAIL to print parameter names for further debugging.

With setting TORCH_DISTRIBUTED_DEBUG to DETAIL I also have :

Parameter at index 73 with name roi_heads.box_predictor.xxx.bias has been marked as ready twice. This means that multiple autograd engine  hooks have fired for this particular parameter during this iteration.

So, technically, there is a problem with roi_heads.box_predictor.xxx. Could not find one. However, with version 1.9.0 the console also outputs this:

[W reducer.cpp:1158] Warning: find_unused_parameters=True was specified in DDP constructor, but did not find any unused parameters in the forward pass. This flag results in an extra traversal of the autograd graph every iteration,  which can adversely affect performance. If your model indeed never has any unused parameters in the forward pass, consider turning this flag off. Note that this warning may be a false positive if your model has flow control causing later iterations to have unused parameters. (function operator())

Turned out to be the root cause. Switching find_unused_parameters to False makes the training run normally. Not sure why this does work now, but I don’t mind.

1 Like

‘Parameter at index 73 with name roi_heads.box_predictor.xxx.bias has been marked as ready twice. This means that multiple autograd engine hooks have fired for this particular parameter during this iteration.’

==> does your program use some activation checkpoint?

3 Likes

I ran into this problem as well - find_unused_parameters=True may cause a parameter to be marked twice. The problem is that in my case find_unused_parameters=True is actually needed.

@Yanli_Zhao Sorry about my ignorance here - I am wondering why activation checkpoint is related to autograd engine hooks? Thanks!

Hi! Have you solved the problem?
I also met the problem described in the main post. And in my case find_unused_parameters=True is necessary. Not sure how to solve it.
Thanks!

I have a setup in which there are two models (f, g) (I’m training f(g)). If I keep find_unused_parameters=True for both models, there is error like yours. When I use find_unused_parameters=True for only the first model, error disappears.

1 Like

Hi Saurabh,

I got the same error and I am using similar structure. May I know how to set the ‘find_unused_parameters=True’ for only the first model?

Thank you very much and I’m looking forward to the reply.

David

model_1 = DDP(model_1, find_unused_parameters=True, device_ids=[rank]
model_2 = DDP(model_2, find_unused_parameters=False, device_ids=[rank]
Hopefully, this works for you.

1 Like