search for: 58970

Tried the following with R --vanilla on the Rv2.4.0 release (see details at the end). I think the script and its comments speaks for itself, but the outcome is certainly not wanted. for (n in 58950:58970) { cat("n=", n, "\n", sep=""); # Clean up first rm(names, x, y); gc(); # Create a named vector of length n # Try with format "%5d" and it works names <- sprintf("%05d", 1:n); x <- seq(along=names); names(x) <- names; #...

CentOS Errata and Security Advisory CESA-2005:802 xloadimage security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2005-802.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/xloadimage-4.1-36.RHEL3.i386.rpm source: updates/SRPMS/xloadimage-4.1-36.RHEL3.src.rpm You may update your CentOS-3 i386 installations by

...it down to an overflow occurring in the stringSubscript function in src/main/subscript.c: at the beginning there's a test ns * nx > 1000 When ns and nx are both large, the product overflows and becomes negative. I'll see if I can fix it. Duncan Murdoch > > for (n in 58950:58970) { > cat("n=", n, "\n", sep=""); > > # Clean up first > rm(names, x, y); gc(); > > # Create a named vector of length n > # Try with format "%5d" and it works > names <- sprintf("%05d", 1:n); > x <- se...

...d locking.tdb.2 22836 22836 W 31051 /usr/sbin/smbd locking.tdb.2 33432 33432 W 10555 /usr/sbin/smbd brlock.tdb.2 58972 58972 18215 /usr/libexec/ctdb/ctdb_lock_helper brlock.tdb.2 58971 58973 W 17216 /usr/sbin/smbd locking.tdb.2 232120 232120 18215 /usr/libexec/ctdb/ctdb_lock_helper brlock.tdb.2 168 58970 17719 /usr/sbin/smbd locking.tdb.2 330636 330636 14579 /usr/sbin/smbd locking.tdb.2 216548 216548 18214 /usr/libexec/ctdb/ctdb_lock_helper locking.tdb.2 216548 216550 W 30945 /usr/sbin/smbd brlock.tdb.2.20170419.102626.697770650.corrupt 160288 160288 12448 /usr/sbin/smbd brlock.tdb.2 216548 216548...

Hello again, Jeremy and other Samba experts, I'm sorry to be such a pain in your neck(s), but I still need your help in looking for help trying to find out why SMB2/3.1.1 in Samba 4.6.5 performs so much worse than SMB/1.5 in Samba 3.6.15 in scenarios with a huge number of small files. As requested by Jeremy, I have done wireshark "pcapng" captures of the four scenarios as