similar to: [LLVMdev] Bad test health

> On Sep 7, 2017, at 12:01 PM, Zachary Turner <zturner at google.com> wrote: > > > > On Thu, Sep 7, 2017 at 11:49 AM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: >> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> To

That's true, but it still requires the person writing the test to be familiar with both formats. Also anything more trivial than dumping a single local variable will probably run into even more issues. For example, The expression parsers each have their own unique quirks, and it might not always be easy to translate. Besides all the format compatibility issues, there's the more general

I was thinking of something along the lines of: // SCRIPT-POSIX: posix/aggregate-indirect-arg.s // SCRIPT-WIN: win/aggregate-indirect-arg.s class SVal { public: ~SVal() {} const void* Data; unsigned Kind; }; void bar(SVal &v) {} class A { public: void foo(SVal v) { bar(v); } }; int main() { SVal v; v.Data = 0; v.Kind = 2142; A a; a.foo(v); return 0; } Then, you could

Timo, I noticed this core dump from imap the other day from one of our users; there was no assertion. GDB output attached, I have saved the core if you need more information. Jeff Earickson Colby College -------------- next part -------------- Script started on Tue May 02 09:15:48 2006 %gdb imap core.jloo GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered

> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To be clear, the tests I'm proposing will have no resemblance whatsoever to GDB, so I would be intentionally forking the set of tests in this regards. So there would very clearly be a paradigm shift in writing CodeView debug info tests (which would be written in JavaScript using

Timo, The gdb analysis is attached. It looks like memory got seriously stomped in this core dump. There was no assert or other useful information in the syslog. My setup: Solaris 9, imap and imaps, mbox format, INBOXes NFS mounted, index files on local ufs filesystem, beta8 configured like so: VERSION=1.0.beta8 CC=gcc CFLAGS="-g -O" CPPFLAGS=-I/opt/openssl/include

Implements more verbose imap logging (when client exits). Similar to existing logging in POP3. Due to the nature of imap and my incomplete understanding (of the dovecot code) the session statistics reported have varying accuracy. Much better than nothing IMO. Cheers, Jens ----------------------------------------------------------------------- 'This mail automatically becomes portable

> > Is this behavior cured, or do you continue to see it? > No, the behavior isn't cured. We still continue to see it with various clients. I have posted a couple of truss outputs, but so far no resolution. Sorry for the slow response. I've been "fighting other fires". Jackie > Jackie Hunt wrote: > >> On Mon, 2007-09-03 at 12:37 +0200, Robert

Hi, 2 or 3 customers have reported that they are having problems downloading their mail via. POP3. I have attached the rawlogs of their transactions and the UID list at the time. Is this because I am using an incompatible UID format or is something else at fault? Deleting the UID list and indexes fixes the problem. I am using Test72. Regards Andrew -- Andrew Hutchings (A-Wing) - Linux

>From the log: Jul 11 13:12:42 mproxy dovecot: imap-login: Login: user=<hildeb>, method=PLAIN, rip=141.42.206.36, lip=141.42.206.11, mpid=27254, TLS, session=<TGwoO1o3id+NKs4k> Jul 11 13:12:44 mproxy dovecot: imap(hildeb)<TGwoO1o3id+NKs4k>: Panic: file imap-client.c: line 854 (client_check_command_hangs): assertion failed: ((io_loop_find_fd_conditions(current_ioloop,