anon-iclr-submission/benchname-bug-localization huggingface dataset:
Repository: dagster-io/dagster
Issue: InputContext has wrong asset key with fan-in

This fails:

```python
from dagster import (
    asset,
    op,
    graph_asset,
    materialize,
    load_assets_from_current_module,
)

from typing import List


@asset
def upstream1():
    return "a"


@asset
def upstream2():
    return "b"


@op
def asset_op(upstream_assets: List[str]):
    assert upstream_assets == ["a", "b"], upstream_assets


@graph_asset
def some_asset(upstream1, upstream2):
    return asset_op([upstream1, upstream2])


if __name__ == "__main__":
    materialize(load_assets_from_current_module())
```

Further investigation traces the problem to this line inside `for_input_manager`:
```python
        asset_key = self.job_def.asset_layer.asset_key_for_input(
            node_handle=self.node_handle, input_name=name
        )
```

The arguments being supplied to `asset_key_for_input` will be the same for all the fanned-in inputs, even though they come from different assets.

To fix this, I think we'd need to at least modify `AssetLayer._asset_keys_by_node_input_handle` to capture the fact that a single input can correspond to multiple upstream assets.


Changed files:
python_modules/dagster/dagster/_core/execution/context/system.py

diff --git a/python_modules/dagster/dagster/_core/execution/context/system.py b/python_modules/dagster/dagster/_core/execution/context/system.py
index a9c11d2a67..a16a471aba 100644
--- a/python_modules/dagster/dagster/_core/execution/context/system.py
+++ b/python_modules/dagster/dagster/_core/execution/context/system.py
@@ -625,9 +625,10 @@ def for_input_manager(
         else:
             upstream_output = artificial_output_context
 
-        asset_key = self.job_def.asset_layer.asset_key_for_input(
-            node_handle=self.node_handle, input_name=name
-        )
+        asset_key = upstream_output.asset_key
+        # self.job_def.asset_layer.asset_key_for_input(
+        #     node_handle=self.node_handle, input_name=name
+        # )
         asset_partitions_subset = (
             self.asset_partitions_subset_for_input(name)
             if self.has_asset_partitions_for_input(name)
Repository: pyro-ppl/pyro
Issue: Memory leak using TraceEnum_ELBO

I noticed a major memory leak when training SVI using `TraceEnum_ELBO`.
I initially noticed this in a custom model we are developing but then I found it seems a more general bug.

For example, it affects even the Pyro tutorials GMM example [here](https://pyro.ai/examples/gmm.html). Where memory usage rapidly goes from a couple of hundred MBs to a many **GB**s very quickly!

I have run this Macbook Pro 2019 running MacOS 10.15. To replicate the issue is enough running the notebook linked.

I have tried to comment out the following lines and add a garbage collector call, that reduces the entity of the memory accumulation of one order of magnitude but does not solve the problem completely, which becomes particularly severe for large datasets.

```python
# Register hooks to monitor gradient norms.
# gradient_norms = defaultdict(list)
# for name, value in pyro.get_param_store().named_parameters():
#     value.register_hook(lambda g, name=name: gradient_norms[name].append(g.norm().item()))

import gc
losses = []
for i in range(200000):
    loss = svi.step(data)
    #losses.append(loss)
    gc.collect()
``` 

(from [this forum post](https://forum.pyro.ai/t/memory-usage-grows-with-iterations-in-svi-step/4103))

Changed files:
pyro/infer/traceenum_elbo.py

diff --git a/pyro/infer/traceenum_elbo.py b/pyro/infer/traceenum_elbo.py
index 11417183..1514f402 100644
--- a/pyro/infer/traceenum_elbo.py
+++ b/pyro/infer/traceenum_elbo.py
@@ -270,6 +270,7 @@ class BackwardSampleMessenger(pyro.poutine.messenger.Messenger):
         return super().__enter__()
 
     def __exit__(self, exc_type, exc_value, traceback):
+        self.cache.clear()
         if exc_type is None:
             assert not self.sum_dims, self.sum_dims
         return super().__exit__(exc_type, exc_value, traceback)
Repository: pyro-ppl/pyro
Issue: bug with OneCycleLR on Apple Silicone 

### Guidelines

**NOTE:** Issues are for bugs and feature requests only. If you have a question about using Pyro or general modeling questions, please post it on the [forum](https://forum.pyro.ai/).

If you would like to address any minor bugs in the documentation or source, please feel free to contribute a Pull Request without creating an issue first. 

Please tag the issue appropriately in the title e.g. [bug], [feature request], [discussion], etc.

Please provide the following details:
--------------------------------------------------------------------------------------------------
### Issue Description
Provide a brief description of the issue.

### Environment
For any bugs, please provide the following:
 - OS and python version.
 - PyTorch version, or if relevant, output of `pip freeze`.
 - Pyro version: output of `python -c 'import pyro; print pyro.__version__'`

### Code Snippet
Provide any relevant code snippets and commands run to replicate the issue.


Changed files:
pyro/optim/pytorch_optimizers.py

diff --git a/pyro/optim/pytorch_optimizers.py b/pyro/optim/pytorch_optimizers.py
index 57dd4b02..05dfa4db 100644
--- a/pyro/optim/pytorch_optimizers.py
+++ b/pyro/optim/pytorch_optimizers.py
@@ -34,13 +34,16 @@ for _name, _Optim in torch.optim.__dict__.items():
     del _PyroOptim
 
 # Load all schedulers from PyTorch
+# breaking change in torch >= 1.14: LRScheduler is new base class
+if hasattr(torch.optim.lr_scheduler, "LRScheduler"):
+    _torch_scheduler_base = torch.optim.lr_scheduler.LRScheduler
+else:  # for torch < 1.13, _LRScheduler is base class
+    _torch_scheduler_base = torch.optim.lr_scheduler._LRScheduler
+
 for _name, _Optim in torch.optim.lr_scheduler.__dict__.items():
     if not isinstance(_Optim, type):
         continue
-    if (
-        not issubclass(_Optim, torch.optim.lr_scheduler._LRScheduler)
-        and _name != "ReduceLROnPlateau"
-    ):
+    if not issubclass(_Optim, _torch_scheduler_base) and _name != "ReduceLROnPlateau":
         continue
     if _Optim is torch.optim.Optimizer:
         continue
Repository: pyro-ppl/pyro
Issue: model_7 in `examples/contrib/funsor/hmm.py` may have a bug

In the hmm example using funsor, model_7 may have a bug, `x_prev` is initialized but never updated.
https://github.com/pyro-ppl/pyro/blame/38facc126103ef77604d0d47dfde94839ad9dc69/examples/contrib/funsor/hmm.py#L610



Changed files:
examples/contrib/funsor/hmm.py

diff --git a/examples/contrib/funsor/hmm.py b/examples/contrib/funsor/hmm.py
index caa67a8e..ce8d26a7 100644
--- a/examples/contrib/funsor/hmm.py
+++ b/examples/contrib/funsor/hmm.py
@@ -626,6 +626,7 @@ def model_7(sequences, lengths, args, batch_size=None, include_prior=True):
                         dist.Bernoulli(probs_y[x_curr.squeeze(-1)]),
                         obs=Vindex(sequences)[batch, t],
                     )
+                x_prev = x_curr
 
 
 # Let's see how vectorizing time dimension changes the shapes of sample sites:
@@ -644,11 +645,11 @@ def model_7(sequences, lengths, args, batch_size=None, include_prior=True):
 #                      value       16  1  1  1 |
 #                   y_0 dist       16 10  1 51 |
 #                      value          10  1 51 |
-#  x_slice(0, 71, None) dist          10 71  1 |
+#  x_slice(0, 71, None) dist       16 10 71  1 |
 #                      value    16  1  1  1  1 |
 #  y_slice(0, 71, None) dist    16  1 10 71 51 |
 #                      value          10 71 51 |
-#  x_slice(1, 72, None) dist          10 71  1 |
+#  x_slice(1, 72, None) dist    16  1 10 71  1 |
 #                      value 16  1  1  1  1  1 |
 #  y_slice(1, 72, None) dist 16  1  1 10 71 51 |
 #                      value          10 71 51 |