jiebi/CodeConvo huggingface dataset:
Change:
c[1].fill_(20) self.assertEqual(c[1], c[3], 0) <ins> def test_from_buffer(self): a = bytearray([1, 2, 3, 4]) self.assertEqual(torch.ByteStorage.from_buffer(a).tolist(), [1, 2, 3, 4]) shorts = torch.ShortStorage.from_buffer(a, 'big') self.assertEqual(shorts.size(), 2) self.assertEqual(shorts.tolist(), [258, 772]) ints = torch.IntStorage.from_buffer(a, 'little') self.assertEqual(ints.size(), 1) self.assertEqual(ints[0], 67305985) f = bytearray([0x40, 0x10, 0x00, 0x00]) floats = torch.FloatStorage.from_buffer(f, 'big') self.assertEqual(floats.size(), 1) self.assertEqual(floats[0], 2.25) </ins> if __name__ == '__main__': unittest.main()

Discussion:
<!-- A clear and concise description of what the bug is. --The target name is used by a test executable in mkldnn. Steps to reproduce the behavior: BUILDTEST=1 build <!-- If you have a code sample, error messages, stack traces, please provide it here as well --<!-- A clear and concise description of what you expected to happen. --CMake configure passes. Please copy and paste the output from our (or fill out the checklist below manually). You can get the script and run it with: PyTorch Version (e.g., 1.0): v1.5.0-rc2 OS (e.g., Linux): Windows How you installed PyTorch (, , source): source Build command you used (if compiling from source): python build Python version: 3.x CUDA/cuDNN version: 9.2 / 10.1 / 10.2 / NA GPU models and configuration: Tesla M60 Any other relevant information: <!-- Add any other context about the problem here. --We should not build tests for mkldnn.
I have encountered the same error, how do I resolve it?
It is actually mkldnn that is out of sync. So running the following script should help.
Thanks a lot for this I posted this on the PyTorch Discussions but to no avail, and now I've finally understood the reason of this error. Thanks a lot. Surprisingly, for me the build works out if I build from the master repo, but changing to a different version always fails.
Change:
# use faster C loader if available from yaml import CLoader as YamlLoader except ImportError: <del> from yaml import YamlLoader </del> <ins> from yaml import Loader as YamlLoader </ins> GENERATED_COMMENT = CodeTemplate("""

Discussion:
Build error: According to , the should be modified as:
I the same problem when installing pytorch from source. You mean the file is wrong?
Although the PyYAML documentation site suggests that is possible, I could not perform it. That is a reason for the failing. This has been reported as well: I believe that the should have this instead: In fact when I did this: This indicates that the import didn't happen in PyYAML itself.
you guys are right, the case has to be modified to: . The original issue (my guess) is that your pyyaml had some compile error and the CLoader wasn't successfully installed.
Change:
TEST_CUDA = torch.cuda.is_available() TEST_MULTIGPU = TEST_CUDA and torch.cuda.device_count() >= 2 TEST_CUDNN = TEST_CUDA and torch.backends.cudnn.is_acceptable(torch.cuda.FloatTensor(1)) <ins> TEST_CUDNN_VERSION = TEST_CUDNN and torch.backends.cudnn.version() </ins> PRECISION = 1e-5 module_tests = [

Discussion:
cuDNN backend for RNN stabilizes at large mem usage. The following code stabilizes for me at 14+GiB reported by nvidia-smi. The same RNN without cuDNN uses <2.5GiB.
Oops... any idea what's going on with the garbage collector in this case?
are you running this on a P100 GPU?
Yes, I observe similar behavior on Titan X Pascal
hmmm, do cudnn RNNs have weird memory-oversubscribing properties? If it wasn't for CuDNN RNN, then it's not unreasonable. we use a custom CUDA allocator that will oversubscribe if needed, but will free the memory blocks it's holding onto if it hits OOM / failed allocations.
Tried the same RNN in torch and am getting ~2.6GiB on nvidia-smi.
With cuDNN I'm getting a constant usage of 2241MB on my machine using PyTorch (M40).
are you using cudnnv5, or v6?
v5
no, cudnn does not do memory oversubscribing, and already tried the same network in lua torch with cudnn, where it gets expected memory usage. Also, he is getting OOMs on slightly bigger networks, where apparently caching allocator should have tried to free previous blocks. Interesting that can not repro this.
Just to make sure did you set when you ran? I left it as False in the repro.
I can repro in the docker image built from the current version on P100, and I go OOM after 8 batches with the same image on 1080, which generally should not happen - if there is enough memory to go through 1 batch, memory usage should not increase afterwards.
No, I just copied your script and ran it. Weird thing is that it goes OOM after 18 batches once I enable . Without it memory remains stable.
A lot of cudaMalloc allocations go not through THCudaMalloc, and never get freed:
So not going through THCudaMalloc is actually expected for storages allocated with THCStorage_(newWithSize), but what's not expected is to every time cudaMalloc bytes of rnn workspace, instead of reusing earlier allocations. (~784 MB allocations are for workspace, ~156MB allocations happen somewhere in criterion).
My guess is that the bug is at the Python level.

Either: Something is holding on to a Tensor longer than it should Something is creating a circular reference which prevents quick clean-up
The issue is that in creates cyclic references. It's made worse by the fact that it holds on to more memory than it should (like the workspace). You can see this by adding a as the first line in your for loop. With the explicit call to the GC every iteration, the memory usage doesn't explode.
how can these cyclic references be fixed?
Not sure yet, but I will fix it tomorrow with
Change:
getattr(self, self.id().split(".")[2])() sys.exit(0) <del> def _join_and_reduce(self): </del> <ins> def _join_and_reduce(self, fn): skip_ok = getattr(fn, "skip_if_no_cuda_distributed", False) </ins> for p in self.processes: p.join(self.JOIN_TIMEOUT) <del> self.assertEqual(p.exitcode, 0) </del> <ins> if not skip_ok: self.assertEqual(p.exitcode, 0) if skip_ok: first_process = self.processes[0] # do this first so we don't give an error message about mismatched exit codes if the first isn't valid assert first_process.exitcode == 0 or first_process.exitcode == SKIP_IF_NO_CUDA_EXIT_CODE for p in self.processes: self.assertEqual(p.exitcode, first_process.exitcode) if first_process.exitcode == SKIP_IF_NO_CUDA_EXIT_CODE: raise unittest.SkipTest("cuda is not available") </ins> elif BACKEND == 'mpi': dist.init_process_group(init_method=INIT_METHOD, backend='mpi')

Discussion:
is causing a crash when we try to build pytorch. Crash looks like this: (all times in US/West) Our 7AM, 8AM builds and earlier were all fine but 9AM, 10AM, 11AM builds all crashed with that same traceback. The new import was in which I think went in between 8AM and 9AM today See command below: See here if needed for : <!-- A clear and concise description of what you expected to happen. --Please copy and paste the output from our (or fill out the checklist below manually). You can get the script and run it with: PyTorch Version (e.g., 1.0): building from master OS (e.g., Linux): linux How you installed PyTorch (, , source): source Build command you used (if compiling from source): see above under 'reproduce' Python version: 3.6
maybe easier to read for build command used:
please try in the CircleCi environment?
in our build script seems to have fixed this. Thanks !
Change:
<del> d6015d42d9a1834bc7595c4bd6852562fb80b30b </del> <ins> 23512dbebd44a11eb84afbf53c3c071dd105297e </ins>

Discussion:
*Status could be: ongoing Torch Bench testing is broken with errors that look like Inductor CI has been broken since 5:41 PM PT on June 14, 2024. It was detected the next day and root caused the morning on June 17th. The affected inductor ci jobs (those related to torchbench perf) shall be marked as unstable until this issue is mitigated. We suspect it's due to the numpy 2.0 update. () Ongoing Current plan is for to pin numpy for torchbench workflows TBD
This can be fixed by the following PRs: PyTorch PR: TorchBench PR:
I'll close those unstable issue once trunk recovers
Change:
char *bytes = (char *) data; int64_t remaining = sizeof(real) * storage->size; while (remaining > 0) { <del> ssize_t result = read(fd, bytes, remaining); </del> <ins> // we write and read in 1GB blocks to avoid bugs on some OSes ssize_t result = read(fd, bytes, THMin(remaining, 1073741824)); </ins> if (result <= 0) // 0 means EOF, which is also an error throw std::system_error(result, std::system_category()); bytes += result;

Discussion:
Running this on OSX: More details of failure in Ubuntu 14.04.1 in
Maybe it's caused by a ? I just test this code and it doesn't work (on Mac OS X 10.12.3 with Python 3.6):
That thread links to this one , which says it’s an OS bug and proposes a workaround patch that hasn’t been merged. There’s also a numpy issue thread, which links to this Torch7 commit that implements a workaround
We're doing a loop in case it writes less, but we always pass the full amount of remaining bytes. Putting a cap (std::min with INT_MAX) on the size of a single write might help.
I can't reproduce it on CentOS. I think it might have been a report for a PyTorch version prior to fixing .
Change:
input2 = torch.randn(input_size, requires_grad=True) self.assertEqual(F.cosine_similarity(input1, input2, dim=1).size(), expected_size) <ins> def test_grid_sample_unsupported_mode(self): with self.assertRaisesRegex(NotImplementedError, "nn.functional.grid_sample got unsupported mode: 'garbage'"): F.grid_sample(torch.tensor([]), torch.tensor([]), mode='garbage') </ins> def test_grid_sample(self): def test_cpu_against_cuda(N, C, H, W, padding_mode): def test_shape(N, C, IH, IW, H, W, padding_mode):

Discussion:
The only valid mode is 'bilinear', but one can pass anything to it and it will not complain:
Apparently, the is not passed to the backend function for . I think it should be removed.
Yes. I think the idea is that we'd like to support other modes at some point.
Change:
self.value = value def forward(self, input): <del> return F_ConstantPad2d(pad=self.padding, value=self.value)(input) </del> <ins> return F.pad(input, self.padding, 'constant', self.value) </ins> def __repr__(self): return self.__class__.__name__ + ' ' + str(self.padding)

Discussion:
After merging cuda 12.4 for nightly. I observe following failures: libtorch-cuda124-shared-with-deps-cxx11-abi-build: Build Official Docker Images 124: We need to resolve these before continuing adding CUDA 12.4 CI workflows 0 cc
attempt 3 worked for libtorch build issue:
For Docker image, related discussion:
I will instance a new bug for the docker job failure.

Is there a way to use reflection padding instead of zero padding with nn.Conv2d ? I see there is a but the option is not in nn.Conv2d. Thanks,
are in , but they're not exposed in the docs.
Thanks!
Change:
padding_idx (int, optional): If given, pads the output with zeros whenever it encounters the index. max_norm (float, optional): If given, will renormalize the embeddings to always have a norm lesser than this norm_type (float, optional): The p of the p-norm to compute for the max_norm option <del> scale_grad_by_freq (boolean, optional): if given, this will scale gradients by the frequency of </del> <ins> scale_grad_by_freq (bool, optional): if given, this will scale gradients by the frequency of </ins> the words in the mini-batch. <del> sparse (boolean, optional): if ``True``, gradient w.r.t. weight matrix will be a sparse tensor. See Notes for </del> <ins> sparse (bool, optional): if ``True``, gradient w.r.t. weight matrix will be a sparse tensor. See Notes for </ins> more details regarding sparse gradients. Attributes: weight (Tensor): the learnable weights of the module of shape (num_embeddings, embedding_dim) Shape: <del> - Input: LongTensor `(N, W)`, N = mini-batch, W = number of indices to extract per mini-batch - Output: `(N, W, embedding_dim)` </del> <ins> - Input: LongTensor of arbitrary shape containing the indices to extract - Output: `(*, embedding_dim)`, where `*` is the input shape </ins> Notes: Keep in mind that only a limited number of optimizers support

Discussion:
I have a straightforward use case. Given a token (or word), lookup the embedding of the word, pass that through a linear layer and perform L2 regression. If the token corresponds to the of the embedding layer, throws an error saying OS: macOS High Sierra PyTorch version: 0.3.1 How you installed PyTorch (conda, pip, source): Tried both conda and pip Python version: 3.6.4 CUDA/cuDNN version: CPU GPU models and configuration: NA GCC version (if compiling from source): NA A script to reproduce the bug:
I got the same trouble, and it throw this error after some epochs of training. Does anyone have some solutions?
Change:
weight_data[:] = 4 self.assertEqual(weight_data, all_vars[4].data) <ins> @unittest.skipIf(not TEST_CUDNN, 'CUDNN not available') def test_cudnn_weight_tying(self): rnns = [ nn.LSTM(10, 20, batch_first=True, bidirectional=True), nn.GRU(10, 20, batch_first=True, bidirectional=True), nn.RNN(10, 20, batch_first=True, bidirectional=True) ] for rnn in rnns: rnn.bias_ih_l0_reverse = rnn.bias_ih_l0 rnn.cuda() input = Variable(torch.randn(5, 4, 10).cuda(), requires_grad=True) hx = Variable(torch.randn(2, 5, 20).cuda(), requires_grad=True) all_vars = [input, hx] + list(rnn.parameters()) opt = torch.optim.SGD(rnn.parameters(), lr=0.1) opt.zero_grad() if isinstance(rnn, nn.LSTM): cx = Variable(torch.randn(2, 5, 20).cuda(), requires_grad=True) all_vars[2:2] = [cx] hx = (hx, cx) with warnings.catch_warnings(record=True) as w: output = rnn(input, hx) self.assertEqual(len(w), 1) self.assertIn('weights are not part of single contiguous chunk of memory', w[0].message.args[0]) output[0].sum().backward() opt.step() with warnings.catch_warnings(record=True) as w: output_cuda = rnn(input, hx) rnn.cpu() hx = (hx[0].cpu(), hx[1].cpu()) if isinstance(rnn, nn.LSTM) else hx.cpu() output_cpu = rnn(input.cpu(), hx) self.assertEqual(output_cuda, output_cpu) </ins> @unittest.skipIf(not TEST_CUDA, 'CUDA not available') def test_cuda_rnn_fused(self): def copy_rnn(rnn1, rnn2):

Discussion:
While the fast path for cuDNN RNNs introduced in includes a check intended to fall back to copying weights if weights are moved or aliased, this only works if the aliasing happens after the weights are first compacted. But the most natural place to tie weights is inside a module's method, which runs before , the typical time when is first invoked. Here's an MWE. The three runs (CPU, weight tying before , and weight tying after ) should all give the same results, and they do before , but they have not since:
Change:
#ifndef TH_GENERAL_INC #define TH_GENERAL_INC <ins> #define __STDC_FORMAT_MACROS </ins> #include <stdint.h> #include <stdlib.h> #include <stdio.h>

Discussion:
I am installing PyTorch from source. Python version: 2.7.14. CUDA: 8.0. GPU: gtx1080. GCC: 5.4. Processor: AMD Opteron(tm) Processor 6128 While executing "python install" build completes till 87% but after that I get the following errors And many more messages of the same type regarding errors with 'PRId64' I looked at similar issues online and most of the people facing this issue had an old version of gcc, so I'm a bit confused about what my exact problem is. Also, when I'm installing via conda, the installation completes, but when I run the following bit of code, I get an illegal instruction at the print command That I guess is because of the fact I'm using an AMD processor? Any help will be appreciated. Thanks
looks like the same issue as

I am not able to build the current version. Getting the following error: pytorch/aten/src/TH/generic/THTensorLapack.c:860:7: warning: unused variable ‘n’ [-Wunused-variable] int n = ra-size[1]; ^ make[2]: [] Error 1 make[1]: [] Error 2 make: * [all] Error 2 I am using Anaconda as directed in the readme. I have created a conda environment and have set: export CMAKEPREFIXPATH="/u/anaconda2/envs/pyt4/" As specified here: Thanks
What you posted here is only a warning, and it won't stop the build. Please paste the full log into a GitHub gist and link it here
Hi, Here are the logs: I see it says Could NOT find CUDNN, I am installing it in an env which submit jobs to a cluster, do I need to install CUDNN locally?
what compiler do you have? and what OS are you using? The issue is this:
lsbrelease -a LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 7.2 (Maipo) Release: 7.2 Codename: Maipo uname -a Linux 1 SMP Thu Oct 29 17:29:29 EDT 2015 x8664 x8664 x8664 GNU/Linux
- We are seeing the same error above with the build scripts that you provided in , on PyTorch master. I can bisect and let you know the commit that is breaking the build.
The CPU build script fails with this commit () -
Got the same error when trying to compile under CentOS 7.2.1511 with GCC 4.8 and GCC 5.4 (no newer gcc available on that server).

CC
Searching issues for "PRId64" shows that this error popped up and has been fixed in various places in the pytorch codebase, e.g. The problem seems to be that this format specifier is not defined by default in C++ and/or old gcc versions. A hacky way to fix this is replacing with in the two files currently causing this error on master. A better way is to find the proper place for addding as described in the issue linked above.
Could you try and see if the branch in fixes the issue? I wasn't able to reproduce the compile error locally, but based on the past issues it should be the right fix. Thanks!
your branch compiles without error with GCC 5.4
Change:
PyObject *THPFunction_saved_variables(THPFunction *self, void *_unused) { <del> THPUtils_assert(!self->has_freed_buffers, "Trying to backward through the " "graph second time, but the buffers have already been freed. Please " "specify retain_variables=True when calling backward for the first time."); </del> <ins> THPUtils_assert(!self->has_freed_buffers, ERR_BACKWARD_TWICE); </ins> if (!self->saved_variables) return PyTuple_New(0);

Discussion:
Usually calling backwards twice gives this message: But conv2d just segfaults. $ pt A B Segmentation fault (core dumped)
Change:
tasks or pull requests with your environment details is helpful and appreciated. -  **CI tests failed, what does it mean?** Maybe your PR is based <del> off a broken main bracnh? You can try to rebase your change on top </del> <ins> off a broken main branch? You can try to rebase your change on top </ins> of the latest main branch. You can also see the current status of main branch's CI at https://hud.pytorch.org/. -  **What are the most high risk changes?** Anything that touches build

Discussion:
There is a typo on the , in the Frequently Asked Questions. It says: Is that mean to be a joke (broken branch), or an actual typo? If it is meant to be a joke, please ignore this issue. I will be submitting a PR with the fix for the typo.
A typo for sure. I've force-merged your PR, thanks!
Change:
l1=l, l2=l ) <ins> self.param = Variable(torch.Tensor(3, 5)) </ins> l = nn.Linear(10, 20) n = Net() <del> s = nn.Sequential(l, l, l, l) </del> <ins> s = nn.Sequential(n, n, n, n) </ins> self.assertEqual(num_params(l), 2) <del> self.assertEqual(num_params(n), 2) self.assertEqual(num_params(s), 2) </del> <ins> self.assertEqual(num_params(n), 3) self.assertEqual(num_params(s), 3) def test_modules(self): class Net(nn.Container): def __init__(self): super(Net, self).__init__() self.l1 = l self.l2 = l self.param = Variable(torch.Tensor(3, 5)) l = nn.Linear(10, 20) n = Net() s = nn.Sequential(n, n, n, n) self.assertEqual(list(s.modules()), [s, n, l]) </ins> def test_Sequential_getitem(self): l1 = nn.Linear(10, 20)

Discussion:
While using torch on a Macbook pro with M1 ship, using python 3.8.10 and torch 1.12.1, I came across a weird bug that happened because I forgot to put a tensor on MPS. The reproducible code is the following: As you can see, if is on MPS and on CPU, the line wrongly replaces the index in place of the index . I would expect to have an error saying both tensors should be on the same device instead. I get an error: cc
The error seems to happen somewhere within Also I'm getting a warning "The operator 'aten::nonzero' is not currently supported on the MPS backend and will fall back to run on the CPU. This may have performance implications" when printing tensors on MPS.
Hi - thanks for reporting this issue. This is actually an allowed usecase (copying CPU tensors into MPS tensors / MPS -CPU / MPS -MPS): The issue is on MPS side when copying a CPU tensor into a strided MPS tensor. I'll take a look.
Change:
main_sources += split_types("torch/csrc/cuda/Tensor.cpp") if WITH_NCCL: <del> if SYSTEM_NCCL: </del> <ins> if WITH_SYSTEM_NCCL: </ins> main_libraries += ['nccl'] <ins> include_dirs.append(NCCL_INCLUDE_DIR) library_dirs.append(NCCL_LIB_DIR) </ins> else: main_link_args += [NCCL_LIB] extra_compile_args += ['-DWITH_NCCL']

Discussion:
Currently, you can have a libnccl on your system, and pytorch setup favors that instead of compiling one itself from source. The code that takes care of this is: However, this breaks gloo build because gloo gets a path to NCCL via:
I got the error during the installation: Is it related to this problem?
that's a dupe of
no, that's a consequence of , now you have to do before compiling. I think you don't want to do recursive submodule update, because that will pull in gtest and another copy of nccl.
Alternatively we can pass new flags to gloo to prevent it from using its own NCCL
Thanks works for me.
You can prevent it from using its own nccl, but its cmake still has to be able to find some nccl.
I think should be sufficient. I'm testing.
fixes it when we dont have an external NCCL and pytorch compiles it's own NCCL?
I don't see how NCCLEXTERNAL fixes anything, looks like in gloo NCCLEXTERNAL is used just to set dependency if gloo is compiling its own nccl (which we don't want in any case).
The only thing I tested when I was that the vendored nccl was not being built (even if its submodule was checked out); I tested this by adding an to one of the headers. I'll test with the other configurations.
Actually, there are a few bugs here. First, even though GLOOFLAGS looks like it's setting NCCLROOTDIR: it actually isn't because the gloo invocation is which expands to but only is passed to cmake. Suppose you fix this. nccl is still not going to be picked up, because INSTALLDIR is PyTorch's local install dir, but if you disabled nccl builds, there will never actually be a nccl here. So cmake is just going to do it's standard search to find a nccl somewhere. Inversely, if you ever built nccl, and then turn it off, we will keep picking up that locally built version until you delete it. So we shouldn't do that. Suppose you fix this.

Then I think gloo will (continue to) correctly pick up system nccl and be built with it, and the final thing to fix is that build of PyTorch csrc doesn't know how to search for nccl headers somewhere. This is probably related to . I wonder, maybe we shouldn't do any autodetection at all, and force the user to pass us the include and library paths of nccl if they want to build with system.
FYI, I committed a change to gloo to stop bundling NCCL itself. It will now happily pick up whatever NCCL you give it through NCCLROOTDIR or by trying to find it in the standard systems paths. See facebookincubator/gloo You do have to set to make Gloo try and find it and compile in support.
So to fix this, you should be able to not specify anything aside from if you want to use system NCCL, and add if you have some custom location (either a PyTorch bundled version or a custom install altogether).