search for: ostream

Hi! After upgrade I'm noticing many coredummps, below is backtrace: $ echo "bt"|gdb .... #0 o_stream_zlib_flush (stream=0xc8be5b27640) at ostream-zlib.c:222 222 if (o_stream_zlib_send_flush(zstream) < 0) (gdb) #0 o_stream_zlib_flush (stream=0xc8be5b27640) at ostream-zlib.c:222 #1 0x00007a695e8f09cd in o_stream_flush (stream=stream at entry=0xc8be5b276d0) at ostream.c:147 #2 0x00007a695e83c06f in o_stream_zlib_close (stream=...

Hi Timo, As a follow-up to my earlier email, I've managed to get a few backtraces now. #305439 o_stream_close (stream=0x1680c10) at ostream.c:85 #305440 0x00007ff222f70f3c in o_stream_zlib_send_outbuf (zstream=0x1680b80) at ostream-zlib.c:97 #305441 0x00007ff222f70fef in o_stream_zlib_send_flush (zstream=0x1680b80) at ostream-zlib.c:182 #305442 0x00007ff222f711cb in o_stream_zlib_flush (stream=<optimized out>) at ostream-zlib.c:2...

Hello, I use the zlib and imap_zlib plugins on FreeBSD. As of 2.3.0, my logs are producing these errors every so often, but AFAICT the messages themselves aren't getting corrupted. Panic: file ostream-zlib.c: line 36 (o_stream_zlib_close): assertion failed: (zstream->ostream.finished || zstream->ostream.ostream.stream_errno != 0) Fatal: master: service(imap): child 80128 killed with signal 6 (core not dumped - set service imap { drop_priv_before_exec=yes }) Panic: file ostream-zlib.c: line...

...'s maildir. Well, i try to base it in zlib plugin, with was the o_stream_create_gz(). Inside the o_stream_create_gz has the Output, it's a copy from the original output. I Try to replace this output, with another one, that i try to create to another location, without sucessfull. struct ostream * o_stream_create_X_list(struct ostream *output, struct istream *input, const char *type) { struct emexis_ostream *X_stream; struct ostream *new_output; int fd; fd = open("/tmp/email",O_WRONLY); new_output = o_stream_create_fd_file(fd, 0, TRUE); o_stream_cork(new_output); emexis_stream...

I see this in my logs after 2.3.3: using zlib plugin, ofc. Oct 02 10:01:39 imap(user at example.com)<50643></2k4Sjp3vMqC496W>: Panic: file ostream-zlib.c: line 37 (o_stream_zlib_close): assertion failed: (zstream->ostream.finished || zstream->ostream.ostream.stream_errno != 0 || zstream->ostream.error_handling_disabled) Oct 02 10:01:39 imap(user at example.com)<50643></2k4Sjp3vMqC496W>: Error: Raw backtrace: /usr/lib64...

Previously I had asked how to write then read back IR to/from a file. The write code looked like: LLVMContext ctx; SMDiagnostic diag; Module *m = ParseIRFile( "my_file", diag, ctx ); However, the code I'm trying to retrofit LLVM IR into passes me just a std::ostream&. How can I read IR from a std::ostream? I figured out how to use raw_os_ostream to adapt a std::ostream to a raw_ostream for writing a module, but there's no obvious way to adapt the code for reading, e.g., no MemoryBuffer that adapts a std::ostream (unless I missed it). - Paul

Hi guys Is some one able to explain me, why these errors emerge: gmake[2]: Entering directory `/usr/local/src/llvm/lib/VMCore' Compiling AsmWriter.cpp AsmWriter.cpp: In function `void WriteConstantInt(std::ostream&, const llvm::Constant*, bool, std::map<const llvm::Type*, std::string, std::less<const llvm::Type*>, std::allocator<std::pair<const llvm::Type* const, std::string> > >&, llvm::SlotCalculator*)': AsmWriter.cpp:255: error: ambiguous overload for `std::bas...

...e: > > On 24.12.2017 15:58, Adam Weinberger wrote: >> Hello, >> I use the zlib and imap_zlib plugins on FreeBSD. As of 2.3.0, my logs >> are producing these errors every so often, but AFAICT the messages >> themselves aren't getting corrupted. >> Panic: file ostream-zlib.c: line 36 (o_stream_zlib_close): assertion >> failed: (zstream->ostream.finished || >> zstream->ostream.ostream.stream_errno != 0) >> Fatal: master: service(imap): child 80128 killed with signal 6 (core >> not dumped - set service imap { drop_priv_before_exec=yes...

...MSC_VER typedef __int64 quad_t; typedef unsigned __int64 u_quad_t; typedef __int64 int64_t; typedef unsigned __int64 u_int64_t; #endif /*__GNUC__*/ This tweak seems to work. As far as I can see, correct me if I'm wrong, it is the compiler, that can't figure out which std::basic_ostream to use. Why? > >It appears that your libstdc++ does not support insertion of 64-bit >integers into iostreams. Did I mention that you should try cygwin? ;-) > >-Chris > > > > gmake[2]: Entering directory `/usr/local/src/llvm/lib/VMCore' > > Compiling AsmWriter...

...P -MF backends/brass/.deps/brass_check.Tpo -c ../backends/brass/brass_chec k.cc -DPIC -o backends/brass/.libs/brass_check.o ../backends/brass/brass_check.cc: In static member function `static void BrassTableCheck::check(const char*, const std::string&, brass_revision_number_t*, int, std::ostream&)': ../backends/brass/brass_check.cc:216: error: ambiguous overload for ` std::basic_ostream<char, std::char_traits<char> >& << brass_tablesize_t&' operator /opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc:63: error: candidates are: std::basic_ostream<...

...n i/o-streams are working fine on any kind of mail the test suite is passing through them. But as soon as the zlib plugin is enabled the logs show an cache error: failed: Cached message size larger than expected (214 > 206, box=INBOX, UID=1) I've already double-checked the return values of ostream's sendv and istream's read function. They seem correct (and equal). If the order of the streams are changed (by changing the number in the lib-filename libxx_scrambler.so); meaning that the encryption is done before the compression (which isn't efficient) both streams are working corre...

Hi all, With the newest patches to LLVM, there should be no reason for having "#include <iostream>" in any library source code file, except for lib/ Support/Streams.cpp. Please use the following instead: OLD NEW --- --- std::ostream llvm::OStream std::istream llvm::IStream std::cerr llvm::cerr std::cerr llvm::cout std::cin...

...gt; >> We are pleased to release Dovecot release v2.3.7. > > My upgrade from 2.3.6 to 2.3.7 broke replication (FreeBSD 12.0-STABLE r349799): > > | dovecot[76032]: master: Dovecot v2.3.7 (494d20bdc) starting up for imap, lmtp, sieve > | dovecot[76035]: replicator: Error: file_ostream.net_set_tcp_nodelay((conn:unix:/var/run/dovecot/stats-writer), TRUE) failed: Invalid argument > | dovecot[76035]: replicator: Error: file_ostream.net_set_tcp_nodelay((conn:unix:auth-userdb), TRUE) failed: Invalid argument > | dovecot[76035]: auth: Error: file_ostream.net_set_tcp_nodelay((conn...

Hello Everyone... In zlib save mail have it: struct ostream *output; There is a way to get the file descriptor from output used in ostream zlib plugin ? to get in istream is i_stream_get_fd, but don't have o_stream_get_fd......

On Wed, 7 Jul 2004, Henrik Bach wrote: > This tweak seems to work. > > As far as I can see, correct me if I'm wrong, it is the compiler, that can't > figure out which std::basic_ostream to use. Why? What I'm saying is that it appears that your implementation of operator<< is not functional or is missing. You said that you are using GCC on internix. Is it possible that when you configured/built gcc that it didn't find 64-bit integer support and disabled it or somet...

...P -MF backends/brass/.deps/brass_check.Tpo -c ../backends/brass/brass_chec k.cc -DPIC -o backends/brass/.libs/brass_check.o ../backends/brass/brass_check.cc: In static member function `static void BrassTableCheck::check(const char*, const std::string&, brass_revision_number_t*, int, std::ostream&)': ../backends/brass/brass_check.cc:216: error: ambiguous overload for ` std::basic_ostream<char, std::char_traits<char> >& << brass_tablesize_t&' operator /opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc:63: error: candidates are: std::basic_ostream<...

Dear All, I am currently writing an analysis pass that uses a third-party library. I want to write a print() method for my pass (which takes one of the LLVM raw_ostream objects) and have it use a method from this third-party library to print out data. However, the third-party library uses std::ostream. Is there a way to create a std::ostream from a raw_ostream? -- John T.

Yes, Chris you're right. It seems that my << operator for int64_t is missing in my '/opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc' file. Which ordinary version of GCC are you working with and how do your definition of the << operator for int64_t look like? /Henrik > >Here is an excerpt from the config.log for LLVM: > >configure:19451: checking for int64_t >configure:19476: gcc -c -g -O2 conft...

Hi all, I need to use the printing methods from a third-party library. The problem is those methods use std::cout but the use of std::ostream methods seems to be disabled in latest versions of LLVM. I'm aware of raw_os_ostream (http://llvm.org/doxygen/classllvm_1_1raw__os__ostream.html) which takes a std::ostream as input. E.g., I could do something like: #include "llvm/Support/raw_os_ostream.h" #include "llvm/Suppor...

...2007, at 3:07 PM, Bill Wendling wrote: > >> A debug or release build? >> >> -bw > > Both, actually. Weird. I see a potential problem, though. The code is like this: void dumpToDOUT(SparseBitVector<> *bitmap) { dump(*bitmap, DOUT); } where dump expects an llvm::OStream& for the second argument. However, when NDEBUG is #defined, DOUT is "llvm::OStream(0)", so it can't be passed by reference. -bw