similar to: O_CLOEXEC-like functionality for llvm::raw_fd_ostream

Hi all, In a pass I’m using raw_fd_ostream to write a string to a file. Does raw_fd_ostream guarantee the write is atomic when I do parallel compilation (currently I’m using -j8)? I have some errs() to print information for debugging purposes and I saw that the printed information gets messed up sometime. If I’m writing a string with the format of “A:B:C”, is it possible that I got “A1:B2:C1” and

Hello, The following describes an API change on trunk. The change is not in the 2.6 branch. The raw_fd_ostream class now defaults to overwriting its output file, and the F_Force flag which was introduced only recently is gone. There's a new F_Excl flag to support users wanting the behavior of returning an error if the file exists, though no one actually appears to want this.

I'm getting seemingly odd SegFaults when writing out using a raw_fd_ostream in the current trunk (last version worked, believe it was 153818, or similar). Again, nothing in the release notes... should I be scanning the svn log? For example, I have something like: raw_fd_ostream fout("out.txt", errorStr=""); .... fout<<"Hello World, how are you!"\n";

Dan Gohman wrote: > Hello, > > The following describes an API change on trunk. The change is not in > the 2.6 branch. > > The raw_fd_ostream class now defaults to overwriting its output file, > and the > F_Force flag which was introduced only recently is gone. There's a > new F_Excl flag to > support users wanting the behavior of returning an error if the

It looks like some kind of file IO buffer overflow. I'm not dumping any long strings at one time, but I am keeping the file open for the entire run. I've yet to find a correlation to other C files. On Fri, Oct 26, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm getting seemingly odd SegFaults when writing out using a > raw_fd_ostream in the current

So I did a clean checkout and build and still have this issue, did something changed with the way/when it's getting flushed? My old revision did not have this issue, this is an issue strictly with LLVM it seems. On Fri, Oct 26, 2012 at 3:27 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > It looks like some kind of file IO buffer overflow. I'm not dumping any > long strings

Hi, Chatsiri! > ---------- Forwarded message ---------- > From: Chatsiri Ratana <insiderboy at gmail.com> > Date: Wed, Jun 6, 2012 at 2:15 PM > Subject: [LLVMdev] Compile-rt throw error undeclared identifier 'O_CLOEXEC' > To: llvmdev at cs.uiuc.edu > > > Hello All, > > I build LLVM source code version 3.2 from SVN repository. After I > build

On Wed, Jun 6, 2012 at 5:33 PM, Alexey Samsonov <samsonov at google.com> wrote: > Hi, Chatsiri! > > >> ---------- Forwarded message ---------- >> From: Chatsiri Ratana <insiderboy at gmail.com> >> Date: Wed, Jun 6, 2012 at 2:15 PM >> Subject: [LLVMdev] Compile-rt throw error undeclared identifier >> 'O_CLOEXEC' >> To: llvmdev at

On Wed, Jul 31, 2019 at 04:31:32PM -0500, Eric Blake wrote: > This reverts commit 25206df20275aeff346d9b86adf5e9be99cc9e43. > > An upcoming patch wants to ensure no leaked fds from the server to a > child process. POSIX has required O_CLOEXEC since 2008, and although > current POSIX doesn't yet specify full atomic interfaces everywhere > such as SOCK_CLOEXEC, it does have

You can see that currently we leak the virtio-serial file descriptor into child processes. ><fs> debug fds '' 0 /dev/console 1 /dev/console 2 /dev/console 3 /dev/vport0p1 4 /proc/252/fd ><fs> debug sh 'ls -l /proc/self/fd' total 0 lr-x------ 1 root root 64 Aug 27 15:14 0 -> /dev/null l-wx------ 1 root root 64 Aug 27 15:14 1 -> pipe:[5124] l-wx------ 1

Dear all, Consider there is a program that writes to stdout using two different raw_fd_ostream-s: #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; int main() { raw_fd_ostream S(STDOUT_FILENO, false); outs() << "Hello"; S << ", world!";

On 8/1/19 4:15 AM, Richard W.M. Jones wrote: > On Thu, Aug 01, 2019 at 10:06:01AM +0100, Richard W.M. Jones wrote: >> As far as I can see Haiku (hrev52698) has O_CLOEXEC but NOT >> SOCK_CLOEXEC. As this version is a little old I'll do an update and >> see if newer versions support it. > > I'm on hrev53313+1 which also doesn't appear to have SOCK_CLOEXEC

On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Dear all, > > Consider there is a program that writes to stdout using two different > raw_fd_ostream-s: raw_fd_ostream does buffered I/O, so it's not really meant to be used like this. > #include "llvm/LLVMContext.h" > #include "llvm/Module.h" > #include

On 6/2/20 7:27 AM, Richard W.M. Jones wrote: > Use an extensible buffer (a vector<char>) when reading > /proc/self/cmdline. > > Tidy up some error messages. > --- > plugins/vddk/reexec.c | 57 ++++++++++++++++++++++++++----------------- > 1 file changed, 35 insertions(+), 22 deletions(-) > > @@ -80,42 +95,40 @@ perform_reexec (const char *env, const char

Small improvements and fixes to urandom.

https://bugzilla.redhat.com/show_bug.cgi?id=1123007 This is version 2 of the patch which avoids incorrectly closing stderr, so we can still see debug and error messages. Rich.

This reverts commit 25206df20275aeff346d9b86adf5e9be99cc9e43. An upcoming patch wants to ensure no leaked fds from the server to a child process. POSIX has required O_CLOEXEC since 2008, and although current POSIX doesn't yet specify full atomic interfaces everywhere such as SOCK_CLOEXEC, it does have an open bug since 2014 [1] recommending the full set of interfaces that will be mandatory

This reverts commit 25206df20275aeff346d9b86adf5e9be99cc9e43, and temporarily breaks compilation on Haiku which has O_CLOEXEC but lacks SOCK_CLOEXEC [1]. An upcoming patch wants to ensure no leaked fds from the server to a child process. POSIX has required O_CLOEXEC since 2008, and that is long enough that we should start blindly relying on it. Meanwhile, POSIX doesn't yet specify full

Hello All, I build LLVM source code version 3.2 from SVN repository. After I build source code of LLVM include "compiler-rt"(Compiler-rt at revision 158057. ) and "clang" are represent an error as below. make[5]: Entering directory `/san01/home/chatsiri/workspacecpp/llvm-svn/projects/compiler-rt' COMPILE: clang_linux/asan-x86_64/x86_64:

On Thu, Aug 01, 2019 at 10:06:01AM +0100, Richard W.M. Jones wrote: > As far as I can see Haiku (hrev52698) has O_CLOEXEC but NOT > SOCK_CLOEXEC. As this version is a little old I'll do an update and > see if newer versions support it. I'm on hrev53313+1 which also doesn't appear to have SOCK_CLOEXEC (nor does it have accept4). Rich. -- Richard Jones, Virtualization