ernie-research/MEnvBench huggingface dataset:
Repository: RobotLocomotion/drake (C++)

Issue:
URDF parser: mimic joint with multiple model instances does not parse
### What happened?

When processing model directives that have multiple instances of the same gripper with a mimic joint, the parser crashes part way through with the error shown below. A stack trace points to https://github.com/RobotLocomotion/drake/blob/ce83cacd7216d73a1239361f0971c7b7a66f0965/multibody/parsing/detail_urdf_parser.cc#L680

### Version

7d55aff3225da608d0fd5a64b8232b29e42ed580

### What operating system are you using?

Ubuntu 22.04

### What installation option are you using?

compiled from source code using Bazel

### Relevant log output

```shell
terminate called after throwing an instance of 'std::logic_error'
  what():  HasJointNamed(): A Joint named 'panda_finger_joint2' appears in multiple model instances (right::panda_hand, left::panda_hand); you must provide a model_instance argument to disambiguate.
```



Discussion: Thanks, Dale. Working now.



Fix (patch):
diff --git a/multibody/parsing/detail_urdf_parser.cc b/multibody/parsing/detail_urdf_parser.cc
index 8f827542e5fa..9e1dd7a580c9 100644
--- a/multibody/parsing/detail_urdf_parser.cc
+++ b/multibody/parsing/detail_urdf_parser.cc
@@ -677,7 +677,7 @@ void UrdfParser::ParseMimicTag(XMLElement* node) {
   ParseScalarAttribute(mimic_node, "multiplier", &gear_ratio);
   ParseScalarAttribute(mimic_node, "offset", &offset);
 
-  if (!plant->HasJointNamed(name)) {
+  if (!plant->HasJointNamed(name, model_instance_)) {
     // This can currently happen if we have a "floating" joint, which does
     // not produce the actual QuaternionFloatingJoint above.
     Warning(*mimic_node,
@@ -688,7 +688,7 @@ void UrdfParser::ParseMimicTag(XMLElement* node) {
     return;
   }
 
-  const Joint<double>& joint0 = plant->GetJointByName(name);
+  const Joint<double>& joint0 = plant->GetJointByName(name, model_instance_);
   const Joint<double>& joint1 =
       plant->GetJointByName(joint_to_mimic, model_instance_);
Repository: RobotLocomotion/drake (C++)

Issue:
Add a function to scale Hyperellipsoids 
There is built in functionality to scale HPolyhedrons (HPolyhedron::Scale) but not hyperellipsoids. I wished to find the approximate volume of a small high-dimensional polyhedron using the MaximumLargestInscribedEllipsoid method. The solver (not using an initial guess) was required to converge to an appropriate scale (which could be anywhere from ~1e-6 to 1e-20). Instead, it seemed more appropriate to scale the hpolyhedron by some factor, 'r', then scale the inscribed ellipsoid down by the same factor. before finding the volume. 

Similar to HPolyhedron::Scale(), a Hyperellipsoid::Scale(double 'r') might be useful. For every point x on the boundary of the original ellipsoid, there would be an associated x' = r*(x-center) + center on the boundary of the returned ellipsoid. This could simply be done by uniformly scaling 'A', resulting in Hyperellipsoid(A_ / r,  center_). 

While this could have been certainly done without the need for a specialized scaling method, I figured that it seemed a natural addition. I have linked a possible solution and test [here](https://github.com/RobotLocomotion/drake/compare/master...Akshay5312:drake:master).




Fix (patch):
diff --git a/geometry/optimization/hyperellipsoid.cc b/geometry/optimization/hyperellipsoid.cc
index 5af391535044..66a1afca68f1 100644
--- a/geometry/optimization/hyperellipsoid.cc
+++ b/geometry/optimization/hyperellipsoid.cc
@@ -175,6 +175,12 @@ std::pair<double, VectorXd> Hyperellipsoid::MinimumUniformScalingToTouch(
                                      result.GetSolution(x));
 }
 
+Hyperellipsoid Hyperellipsoid::Scale(double scale) const {
+  DRAKE_THROW_UNLESS(scale > 0);
+  return Hyperellipsoid(A_ / std::pow(scale, 1.0 / ambient_dimension()),
+                        center_);
+}
+
 Hyperellipsoid Hyperellipsoid::MakeAxisAligned(
     const Eigen::Ref<const VectorXd>& radius,
     const Eigen::Ref<const VectorXd>& center) {
diff --git a/geometry/optimization/hyperellipsoid.h b/geometry/optimization/hyperellipsoid.h
index ef8b4b1b2e2a..da84ba23b155 100644
--- a/geometry/optimization/hyperellipsoid.h
+++ b/geometry/optimization/hyperellipsoid.h
@@ -74,6 +74,15 @@ class Hyperellipsoid final : public ConvexSet {
   std::pair<double, Eigen::VectorXd> MinimumUniformScalingToTouch(
       const ConvexSet& other) const;
 
+  /** Results a new Hyperellipsoid that is a scaled version of `this` about the
+  center. Any point on the boundary of the ellipsoid, x, is now translated to a
+  new point, x*, such that ||x* - center|| = ||x - center|| *
+  pow(scale, 1.0/ambient_dimension()). The volume of the resulting shape is
+  scaled up by 'scale'.
+  @pre `scale` > 0.
+  */
+  [[nodiscard]] Hyperellipsoid Scale(double scale) const;
+
   /** Constructs a Ellipsoid shape description of this set.  Note that the
   choice of ellipsoid is not unique.  This method chooses to order the Ellipsoid
   parameters a ≥ b ≥ c.
Repository: uxlfoundation/oneTBB (C++)

Issue:
concurrent_unordered_map.reserve(0) hangs.
I've observed that calling reserve on a concurrent_unordered_map with a size of 0 causes the program to hang. Here is an MWE that reproduces the problem on Ubuntu 22.10 with gcc 12.2.0 

```
#include<iostream>
#include<oneapi/tbb/concurrent_vector.h>
#include<oneapi/tbb/concurrent_unordered_map.h>

template <typename Container>
void do_work(Container& t_cont){
    std::cout << "Printing container size to make sure compiler doesn't optimize it away: " << t_cont.size() << std::endl;
}

int main() {
   /* Vector works fine. Should see the print statement happen */
   oneapi::tbb::concurrent_vector<int> my_vec;
   my_vec.reserve(0);
   do_work(my_vec);

   oneapi::tbb::concurrent_unordered_map<int,int> my_map;
   my_map.reserve(0); 
   do_work(my_map); // Never gets here.
   return 0;
}
```

I have not tested with other container types nor have I dug deep into the source to figure out why this happens, but I imagine a quick `if (requested_size == 0) { return;}` would fix it.


Discussion: @bwhitchurch, thank you for reporting the issue. I will take a look into sources more deeply to fix that.



Fix (patch):
diff --git a/include/oneapi/tbb/detail/_concurrent_unordered_base.h b/include/oneapi/tbb/detail/_concurrent_unordered_base.h
index 4cbf91ad84..ade91c330f 100644
--- a/include/oneapi/tbb/detail/_concurrent_unordered_base.h
+++ b/include/oneapi/tbb/detail/_concurrent_unordered_base.h
@@ -1,5 +1,5 @@
 /*
-    Copyright (c) 2005-2022 Intel Corporation
+    Copyright (c) 2005-2023 Intel Corporation
 
     Licensed under the Apache License, Version 2.0 (the "License");
     you may not use this file except in compliance with the License.
@@ -677,13 +677,17 @@ class concurrent_unordered_base {
         size_type current_bucket_count = my_bucket_count.load(std::memory_order_acquire);
         size_type necessary_bucket_count = current_bucket_count;
 
-        do {
-            // TODO: Log2 seems useful here
-            while (necessary_bucket_count * max_load_factor() < elements_count) {
+        // max_load_factor() is currently unsafe, so we can assume that my_max_load_factor
+        // would not be changed during the calculation
+        // TODO: Log2 seems useful here
+        while (necessary_bucket_count * max_load_factor() < elements_count) {
                 necessary_bucket_count <<= 1;
-            }
-        } while (current_bucket_count >= necessary_bucket_count ||
-                 !my_bucket_count.compare_exchange_strong(current_bucket_count, necessary_bucket_count));
+        }
+
+        while (!my_bucket_count.compare_exchange_strong(current_bucket_count, necessary_bucket_count)) {
+            if (current_bucket_count >= necessary_bucket_count)
+                break;
+        }
     }
 
     // Observers
Repository: microsoft/wil (C++)

Issue:
<wil/safecast.h> should have a helper that can cast larger with zero-extension of signed types
I am trying to work through some suppressed compiler warnings in one of our code bases.  Many of the suppressed warnings are [C4312](https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4312?view=msvc-170).  This warning is saying that if a signed integer is cast upwards into a pointer type it may become unsafe if the original value was negative.    The cast will fill in the upper bits with ones, which would change the pointer to some address in the kernel address space.

This new helper aims to help with that by casting upwards with 0s as the upper bits.  That will avoid changing the value to something unsafe if it really is treated as a pointer.

(PR to follow shortly)



Fix (patch):
diff --git a/include/wil/safecast.h b/include/wil/safecast.h
index e3690975..659dc15e 100644
--- a/include/wil/safecast.h
+++ b/include/wil/safecast.h
@@ -44,6 +44,12 @@ namespace details
     template <typename NewT, typename OldT>
     constexpr bool both_integral_v = wistd::is_integral<NewT>::value && wistd::is_integral<OldT>::value;
 
+    // Helper template to determine that the cast from OldT to NewT is going to sign extend the
+    // value.  This is only true when the size of NewT is larger than OldT and OldT is signed.
+    template <typename NewT, typename OldT>
+    constexpr bool is_sign_extending_cast_v =
+        (sizeof(NewT) >= sizeof(OldT)) && both_integral_v<NewT, OldT> && wistd::is_signed_v<OldT>;
+
     // Note on native wchar_t (__wchar_t):
     //      Intsafe.h does not currently handle native wchar_t. When compiling with /Zc:wchar_t-, this is fine as wchar_t is
     //      typedef'd to unsigned short. However, when compiling with /Zc:wchar_t or wchar_t as a native type, the lack of
@@ -374,6 +380,22 @@ HRESULT safe_cast_nothrow(const OldT var, NewT* newTResult)
     *newTResult = static_cast<NewT>(var);
     return S_OK;
 }
+
+// This conversion takes a signed integer value and grows it with the upper bits set to zero.  This is
+// useful when the resulting value is cast to a pointer type as it prevents the upper bits from being fill
+// which would adjust the pointed-to address.
+//
+// For example:
+//      wil::safe_zero_extending_cast<ULONG_PTR>(-1)
+// will return 0x00000000`FFFFFFFF on a 64-bit system.
+template <typename NewT, typename OldT, wistd::enable_if_t<details::is_sign_extending_cast_v<NewT, OldT>, int> = 0>
+NewT safe_zero_extending_cast(const OldT var)
+{
+    // The first cast is to an unsigned type of the same size as the original.  The second cast is to the
+    // larger type.  Being an unsigned cast, the upper bits are zeroed out.
+    using unsigned_old_t = wistd::make_unsigned_t<OldT>;
+    return static_cast<NewT>(static_cast<unsigned_old_t>(var));
+}
 } // namespace wil
 
 #endif // __WIL_SAFECAST_INCLUDED
Repository: microsoft/wil (C++)

Issue:
BuildAndTest timeout should be shorter than 6 hours
Runs seem to take ~30 minutes so a 60-minute timeout would provide 2x overhead just in case.  The five additional hours of runtime is wasteful when something stops making progress.

See: https://github.com/microsoft/wil/blob/f0c6a81c0c9a4b23b6801f40554b8bec425a83b4/scripts/azure-pipelines.yml#L39


Discussion: For those curious, the pipeline used to be sequential meaning all binaries and tests were built/run on a single machine. At that time, a max timeout of 6 hours was pretty necessary. We have since parallelized the pipeline making this long of a timeout unnecessary. 60 min sounds like a good number.



Fix (patch):
diff --git a/include/wil/cppwinrt_notifiable_module_lock.h b/include/wil/cppwinrt_notifiable_module_lock.h
index 8e85f8fe..3ae9221c 100644
--- a/include/wil/cppwinrt_notifiable_module_lock.h
+++ b/include/wil/cppwinrt_notifiable_module_lock.h
@@ -53,7 +53,10 @@ struct notifiable_module_lock_base
         if (remaining == 0)
         {
             std::atomic_thread_fence(std::memory_order_acquire);
-            notifier();
+            if (notifier) // Protect against callback not being set yet
+            {
+                notifier();
+            }
         }
         else if (remaining < 0)
         {
@@ -74,6 +77,11 @@ struct notifiable_module_lock_base
         notifier = std::forward<Func>(func);
     }
 
+    void set_notifier(std::nullptr_t) noexcept
+    {
+        notifier = nullptr;
+    }
+
 private:
     std::atomic<int32_t> m_count{0};
     std::function<void()> notifier{};
diff --git a/scripts/azure-pipelines.yml b/scripts/azure-pipelines.yml
index d7ace34f..1e9dacd8 100644
--- a/scripts/azure-pipelines.yml
+++ b/scripts/azure-pipelines.yml
@@ -36,7 +36,7 @@ jobs:
     displayName: 'Check Formatting of Changes'
 
 - job: BuildAndTest
-  timeoutInMinutes: 360
+  timeoutInMinutes: 60
 
   variables:
     compilers: 'clang,msvc'
Repository: root-project/root (C++)

Issue:
Bug in TKDE::Fill
Using TKDE::Fill on an empty TKDE does not work.
See https://root-forum.cern.ch/t/using-tkde-fill/44315

Example code to reproduce it:
```
auto kde = new TKDE(0, nullptr, 0, 5, "", 1); // or variations
for (unsigned int i = 0; i < 100; i++) { kde->Fill(gRandom->Gaus(2,1)); }
kde->GetValue(2); // return a nan
```

The code works in 6.16 ROOT version, but not 6.18



Fix (patch):
diff --git a/hist/hist/src/TKDE.cxx b/hist/hist/src/TKDE.cxx
index b95f4f0050a4c..b5529ecc7a472 100644
--- a/hist/hist/src/TKDE.cxx
+++ b/hist/hist/src/TKDE.cxx
@@ -518,7 +518,15 @@ void TKDE::InitFromNewData() {
    if (fUseMirroring) {
       SetMirroredEvents();
    }
+   else {
+      // to set fBinCount and fSumOfCounts
+      SetBinCountData();
+   }
    // in case of I/O reset the kernel
+   if (!fKernelFunction) SetKernelFunction(nullptr);
+
+   SetKernel();
+   
 }
 
 ///////////////////////////////////////////////////////////////////////////////////////////////////////
@@ -876,6 +884,9 @@ void TKDE::SetBinCountData() {
       }
       fBinCount.clear();
    }
+   if (fSumOfCounts == 0) {
+      Warning("SetBinCountData()", "Empty sum of counts, might lead to nan/inf errors when normalizing.");
+   }
 }
 
 ////////////////////////////////////////////////////////////////////////////////
@@ -1015,7 +1026,7 @@ Double_t TKDE::TKernel::operator()(Double_t x) const {
    Bool_t useCount = (fKDE->fBinCount.size() == n);
    // also in case of unbinned unweighted data fSumOfCounts is sum of events in range
    // events outside range should be used to normalize the TKDE ??
-   Double_t nSum = fKDE->fSumOfCounts; //(useBins) ? fKDE->fSumOfCounts : fKDE->fNEvents;
+   Double_t nSum = fKDE->fSumOfCounts; //(useCount) ? fKDE->fSumOfCounts : fKDE->fNEvents;
    //if (!useCount) nSum = fKDE->fNEvents;
    // in case of non-adaptive fWeights is a vector of size 1
    Bool_t hasAdaptiveWeights = (fWeights.size() == n);
Repository: root-project/root (C++)

Issue:
Bug in TDecompBase::DiagProd
### Check duplicate issues.

- [ ] Checked for duplicates

### Description

This line
https://github.com/root-project/root/blob/2b997add1d6b432ce27f35c1cbf385ffdc4a7cd5/math/matrix/src/TDecompBase.cxx#L231
is wrong and leads to a runaway loop until it reaches the limit.
The handbook mentioned in the comment of the function correctly uses ≥1 instead of <1 in its algorithm.
The fix simply consists in changing <1 to ≥1.

Pull request in preparation.

### Reproducer

As it is, the code works, but may lead to reduced numerical precision for big matrices.

### ROOT version

all, I guess ?

### Installation method

any

### Operating system

any

### Additional context

_No response_



Fix (patch):
diff --git a/math/matrix/src/TDecompBase.cxx b/math/matrix/src/TDecompBase.cxx
index fa1d254e43912..aa6939c605789 100644
--- a/math/matrix/src/TDecompBase.cxx
+++ b/math/matrix/src/TDecompBase.cxx
@@ -228,7 +228,7 @@ void TDecompBase::DiagProd(const TVectorD &diag,Double_t tol,Double_t &d1,Double
    for (Int_t i = 0; (((i < n) && (t1 !=zero ))); i++) {
       if (TMath::Abs(diag(i)) > tol) {
          t1 *= (Double_t) diag(i);
-         while ( TMath::Abs(t1) < one) {
+         while ( TMath::Abs(t1) >= one) {
             t1 *= sixteenth;
             t2 += four;
             niter2++;
Repository: NixOS/nix (C++)

Issue:
`nix::parseDump` does not require `str("contents")` after `str("regular")`
## Describe the bug

In the function `parse` in src/libutil/archive.cc, [the `if` at line 191](https://github.com/NixOS/nix/blob/35d7719f4649b74a604ac78edd76ff5bd2b564a2/src/libutil/archive.cc#L190) does not have an `else` branch, leading to the string being ignored.

## Steps To Reproduce

1. Run the following script using `zig run` and pump its contents into a file.
```zig
const std = @import("std");

pub fn main() !void {
    var sw = std.fs.File.stdout().writer(&.{});
    const writer = &sw.interface;
    try writer.writeAll(archive);
}

inline fn str(comptime s: []const u8) []const u8 {
    return std.mem.asBytes(&std.mem.nativeToLittle(u64, s.len)) ++
        s ++ &@as([padding(s.len)]u8, @splat(0));
}

inline fn padding(comptime l: u64) u3 {
    return @truncate(-%l);
}

const archive = blk: {
    var cur: []const u8 = "";
    for (tokens) |t| cur = cur ++ str(t);
    break :blk cur;
};

const tokens: []const []const u8 = &.{
    "nix-archive-1",
    "(",
    "type",
    "regular",
    //"executable", "",
    "AAAAAAAA", // something other than "contents" or "executable"
    ")",
};
```

2. Run `nix nar cat ARCHIVE /` on the resulting archive

```
[clevor@clevor-laptop-nixos:/tmp/clevor/bruh]$ zig run create.zig > archive.nar
[clevor@clevor-laptop-nixos:/tmp/clevor/bruh]$ nix nar cat archive.nar /
[clevor@clevor-laptop-nixos:/tmp/clevor/bruh]$ echo $?
0
```

## Expected behavior

```
[clevor@clevor-laptop-nixos:/tmp/clevor/bruh]$ nix nar cat archive.nar /
error: bad archive: expected tag 'contents', got 'AAAAAAAA'
```

## Metadata

```
nix-env (Nix) 2.28.5
```

## Additional context

## Checklist

<!-- make sure this issue is not redundant or obsolete -->

- [x] checked [latest Nix manual] \([source])
- [x] checked [open bug issues and pull requests] for possible duplicates

[latest Nix manual]: https://nix.dev/manual/nix/development/
[source]: https://github.com/NixOS/nix/tree/master/doc/manual/source
[open bug issues and pull requests]: https://github.com/NixOS/nix/labels/bug

---

Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).




Fix (patch):
diff --git a/src/libutil/archive.cc b/src/libutil/archive.cc
index b978ac4dbff..3d96df75e02 100644
--- a/src/libutil/archive.cc
+++ b/src/libutil/archive.cc
@@ -187,8 +187,10 @@ static void parse(FileSystemObjectSink & sink, Source & source, const CanonPath
                 tag = getString();
             }
 
-            if (tag == "contents")
-                parseContents(crf, source);
+            if (tag != "contents")
+                throw badArchive("expected tag 'contents', got '%s'", tag);
+
+            parseContents(crf, source);
 
             expectTag(")");
         });
Repository: moveit/moveit2 (C++)

Issue:
Infinite loop in TOTG if zero max acceleration is specified
### Description

If you pass in a zero max acceleration limit to TOTG, you will actually get stuck in an [infinite loop](https://github.com/ros-planning/moveit2/blob/main/moveit_core/trajectory_processing/src/time_optimal_trajectory_generation.cpp#L520) because of the [`integrateForward()`](https://github.com/ros-planning/moveit2/blob/main/moveit_core/trajectory_processing/src/time_optimal_trajectory_generation.cpp#L512) function.

While zero acceleration limit is physically meaningless since it means the joints won't be able to move, we should at least have an error/warning. Whether we actually throw an exception or just return a no-op trajectory is up to the implementer.

### Your environment
* ROS Distro: Rolling
* OS Version: Ubuntu 22.04



Discussion: Quick comment: you might as well check for 0 vel and 0 jerk limits, too
This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.



Fix (patch):
diff --git a/moveit_core/trajectory_processing/src/time_optimal_trajectory_generation.cpp b/moveit_core/trajectory_processing/src/time_optimal_trajectory_generation.cpp
index 1c4da3dee2..70a6272df1 100644
--- a/moveit_core/trajectory_processing/src/time_optimal_trajectory_generation.cpp
+++ b/moveit_core/trajectory_processing/src/time_optimal_trajectory_generation.cpp
@@ -325,6 +325,12 @@ Trajectory::Trajectory(const Path& path, const Eigen::VectorXd& max_velocity, co
   , time_step_(time_step)
   , cached_time_(std::numeric_limits<double>::max())
 {
+  if (time_step_ == 0)
+  {
+    valid_ = false;
+    RCLCPP_ERROR(LOGGER, "The trajectory is invalid because the time step is 0.");
+    return;
+  }
   trajectory_.push_back(TrajectoryStep(0.0, 0.0));
   double after_acceleration = getMinMaxPathAcceleration(0.0, 0.0, true);
   while (valid_ && !integrateForward(trajectory_, after_acceleration) && valid_)
@@ -566,6 +572,16 @@ bool Trajectory::integrateForward(std::list<TrajectoryStep>& trajectory, double
     trajectory.push_back(TrajectoryStep(path_pos, path_vel));
     acceleration = getMinMaxPathAcceleration(path_pos, path_vel, true);
 
+    if (path_vel == 0 && acceleration == 0)
+    {
+      // The position will never change if velocity and acceleration are zero.
+      // The loop will spin indefinitely as no exit condition is met.
+      valid_ = false;
+      RCLCPP_ERROR(LOGGER, "Error while integrating forward: zero acceleration and velocity. Are any relevant "
+                           "acceleration components limited to zero?");
+      return true;
+    }
+
     if (path_vel > getAccelerationMaxPathVelocity(path_pos) || path_vel > getVelocityMaxPathVelocity(path_pos))
     {
       // Find more accurate intersection with max-velocity curve using bisection
Repository: halide/Halide (C++)

Issue:
A split can use the same var name for inner and outer without error
The following code should throw an error on the call to split but does not. Instead it compiles to a garbage pipeline that sprays writes all over the place.

```
#include "Halide.h"

using namespace Halide;

int main(int argc, char **argv) {
    Var x;
    Func f;
    f(x) = 0;
    f.split(x, x, x, 16, TailStrategy::RoundUp);
    return 0;
}
```



Fix (patch):
diff --git a/src/Func.cpp b/src/Func.cpp
index cc5b8bb5979c..ffb53632f658 100644
--- a/src/Func.cpp
+++ b/src/Func.cpp
@@ -1010,6 +1010,12 @@ void Stage::split(const string &old, const string &outer, const string &inner, c
 
     definition.schedule().touched() = true;
 
+    user_assert(inner != outer) << "In schedule for " << name()
+                                << ", can't split " << old << " into "
+                                << outer << " and " << inner
+                                << " because the new Vars have the same name.\n"
+                                << dump_argument_list();
+
     // Check that the new names aren't already in the dims list.
     for (auto &dim : dims) {
         string new_names[2] = {inner, outer};