similar to: panic with 2.2.10 and GETMETADATA

Hi, I'm trying to use the current version of dovecot as the IMAP server for Kolab and things seem to be working more or less OK, but while working on it I've found a dovecot bug that can probably be fixed quickly by someone familiar with the code. I've found the problem using shared folders, but it is related to ACLs and METADATA. The problem appears when a user only has the

Hello, I have dovecot 2.2.13 instance and I found that (at least for polish language) folder names in GETMETADATA command response are encoded in UTF8. Shouldn't it be converted to UTF7? Both SETMETADATA and GETMETADATA arguments have to be encoded in UTF7, the problem(?) is related only to server response example: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE

This patch adds support for getMetadata to plugins. It could probably use better strings for "core". I need this for my dbus-based configuration GUI. -- Travis Watkins http://www.realistanew.com -------------- next part -------------- A non-text attachment was scrubbed... Name: add_plugin_metadata.patch Type: text/x-patch Size: 2511 bytes Desc: not available Url :

Hi, getMetadata(“dbg”) returns NULL for such a small program as follows: int main(){ char a[10], b[2]; if(a[0] != 0 && a[1] != 0){ strcpy(a, b); } return 0; } The compiling command is: llvm-gcc --emit-llvm -g -c ./src.c I also tried the solutions I found through Google: http://stackoverflow.com/questions/14943447/llvm-line-number-of-an-instruction

Testing URLAUTH in dovecot-2.2.1 plus Timo's recent CATENATE and URLAUTH fixes eventually trips some assertions. No simple sequence of commands always hits these; they appear to be timing-dependent. The first one is: May 02 17:47:17 imap(pid 50490 user submit): Panic: file imap-client.c: line 643 (client_command_free): assertion failed: (client->output_cmd_lock == NULL) The line number

On dovecot 2.2.12 compiled from source I use ActiveSync with kolab-syncroton. When running a test i have this imap log: [29-Mar-2014 22:58:25 +0200]: [F658] S: A0004 OK Getmetadata completed. [29-Mar-2014 22:58:25 +0200]: [F658] C: A0005 SETMETADATA INBOX (/private/vendor/kolab/activesync "{\"DEVICE\":{\"601099122\":{\"ID\":

I''m working in a web service, actually, I have: class UnifiedLoginApi < ActionWebService::API::Base class CLL_Metadata < ActionWebService::Struct member :key, :string member :type, :string member :value, :string member :webapplication_id, :string member :user_tenfold_id, :string member :login_username, :string

On 2016-04-22 09:07 PM, Timo Sirainen wrote: > On 22 Apr 2016, at 15:17, Giovanni S. Fois <giovanni at giovannisfois.net> wrote: >> In order to tell if a mailbox is enabled to send out the notification, the plugin >> looks out for the following mailbox metadata key: >> /private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify >> >> If the

Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) *string getFileDirectory*(*const* Instruction &I){ MDNode *MD = I.getMetadata("dbg"); DICompileUnit compileUnit(MD); return compileUnit.getDirectory().str(); } George On Wed, Oct 3, 2012 at 12:40 PM, Eric Christopher <echristo at gmail.com>wrote: > Without knowing the code that you've written

That's because instructions have a location associated with them, not a compile unit. -eric On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. > > George > > On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: >> >> Here is

Török Edwin wrote: > [snip] >>> Something like this (you can of course cache TheMetadata and MDDbgKind) >>> >>> llvm::MetadataContext *TheMetadata = M->getContext().getMetadata(); >>> MDDbgKind = TheMetadata->getMDKind("dbg"); >>> if (MDDbgKind) { >>> if (MDNode *Dbg = TheMetadata->getMD(MDDbgKind, I)) { >>>

Török Edwin wrote: > [snip] > > Ah, the method got moved to the instruction itself! > > dbgKind = Context->getMDKindID("dbg"); > if (MDNode *Dbg = I->getMetadata(dbgKind)) { > ... > Thanks! This appears to work. I also have code that looks up debug information for GlobalVariables and regular LLVM Value *'s. For the former, I think I can look up

I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. George On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: > Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) > > *string getFileDirectory*(*const* Instruction &I){ > > MDNode *MD = I.getMetadata("dbg"); > > DICompileUnit

Yeah, It looks like I am doing exactly what's in Dwarf*.cpp files, yet I am getting blanks. George On Tue, Oct 2, 2012 at 2:10 PM, Eric Christopher <echristo at gmail.com> wrote: > On Tue, Oct 2, 2012 at 11:00 AM, George Baah <georgebaah at gmail.com> wrote: > > Hi Guys, > > How does one get the directory of the compilation unit in llvm? > > I am using

Hello everybody, I want to get the line number of an instruction (and also of a variable declaration - alloca and global). The instruction is saved in an array of instructions. I have the function:     Constant* metadata::getLineNumber(Instruction* I){         if (MDNode *N = I->getMetadata("dbg")) { // this if is never executed             DILocation Loc(N);             unsigned

As an update, it is a memory problem which I don't know how to fix. I tried to skip the problematic piece of code when in the case when the loop hangs. So I did something like : if( instr ) { LLVMContext& C = instr->getContext(); Value* values[cnt]; errs()<<"\ngy: \n"; if(!(desters==7)){ // this

Hi, I have bitcode files built by LLVM v3.3 and need to process them using v3.4 tools. While I don't expect a lot of backward compatibility in LLVM, luckily it seems everything's working fine, except for reading source line information attached to instructions. I use this piece of code [0] to get source line information. For v3.4, instruction.getMetadata returns NULL. I used llvm-dis to

I've started work on a rewrite of sorts for the dbus plugin that changes how it listens/responds to messages to make it possible to generate introspection data. The main changes are registering every plugin, screen, option, etc with dbus_connection_register_object_path and using libxml2 to generate the introspection data. This more or less works I just need to hook up the rest of the methods

Hello, Horde (http://horde.org) has the ability to store its preferences direct into a users imap mailbox using imap metadata extension. There are two implementations of the imap extension. 1. a dovecot plugin: http://hg.dovecot.org/dovecot-metadata-plugin 2. dovecot itself: http://www.dovecot.org/list/dovecot/2013-November/093243.html I setup Horde and dovecot-2.2.5 to use this extension and

Hi, I don't know much about this issue, but this malloc error won't be solved by a change to delete[] or free. In fact, if you use the incorrect one for simple types, you may not notice it. The error you have seems to me like a memory corruption because you went out of bound and corrupted the memory somewhere, Valgrind may help you figure out what is going on. Cheers, Matthieu