similar to: assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)

The bug happens not very often, it might need a week to get a core file. Il giorno ven 21 dic 2018 alle ore 15:18 Aki Tuomi < aki.tuomi at open-xchange.com> ha scritto: > > On 21.12.2018 14.49, Giacomo wrote: > > I'm running the following: > > > > # 2.3.4 (0ecbaf23d): /usr/local/etc/dovecot/dovecot.conf > > # OS: FreeBSD 11.2-RELEASE-p4 amd64 > > #

I've just enabled core dumps on the involved FreeBSD system. Let's see if it dumps something.. Il giorno dom 20 gen 2019 alle ore 19:16 Stephan Bosch <stephan at rename-it.nl> ha scritto: > Hi Giacomo, > > Op 21/12/2018 om 16:16 schreef Giacomo: > > The bug happens not very often, it might need a week to get a core file. > > Any luck getting a core file? >

Op 9-2-2019 om 19:27 schreef Giacomo via dovecot: > I got a core file this morning. > > opening it with gdb I get this: > > (gdb) core imap.core > Core was generated by `dovecot/imap'. > Program terminated with signal 6, Aborted. > #0? 0x0000000011c1347a in ?? () > (gdb) bt > #0? 0x0000000011c1347a in ?? () > #1? 0x0000000011c13444 in ?? () > #2?

On 21.12.2018 14.49, Giacomo wrote: > I'm running the following: > > # 2.3.4 (0ecbaf23d): /usr/local/etc/dovecot/dovecot.conf > # OS: FreeBSD 11.2-RELEASE-p4 amd64?? > # FS: ZFS > > auth_mechanisms = plain login > auth_username_format = %Ln > listen = * > mail_location = maildir:~/Maildir > namespace inbox { > ? inbox = yes > ? location =? > ? mailbox

Hi Giacomo, Op 21/12/2018 om 16:16 schreef Giacomo: > The bug happens not very often, it might need a week to get a core file. Any luck getting a core file? Regards, Stephan. > > > Il giorno ven 21 dic 2018 alle ore 15:18 Aki Tuomi > <aki.tuomi at open-xchange.com <mailto:aki.tuomi at open-xchange.com>> ha > scritto: > > > On 21.12.2018 14.49,

I got a core file this morning. opening it with gdb I get this: (gdb) core imap.core Core was generated by `dovecot/imap'. Program terminated with signal 6, Aborted. #0 0x0000000011c1347a in ?? () (gdb) bt #0 0x0000000011c1347a in ?? () #1 0x0000000011c13444 in ?? () #2 0x0000000000018dee in ?? () #3 0x306db139575f3b0d in ?? () #4 0x00007fffffffc144 in ?? () #5 0x0000000000000000 in

Hi, one of my mailboxes returns following error when I run doveadm index on it: Panic: file charset-iconv.c: line 85 (charset_to_utf8_try): assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE) OS: FreeBSD 10.2 Dovecot: 2.1.19 Tika: 1.10 SOLR: 5.3.1 Running doveadm -D index does not show any more information indicating what causes this error (mail/folder/...) How I can find what is

Timo Sirainen wrote: > On 05 Oct 2015, at 22:05, Nick Rosier<nick+dovecot at bunbun.be> wrote: >> Hi, >> >> one of my mailboxes returns following error when I run doveadm index on it: >> >> Panic: file charset-iconv.c: line 85 (charset_to_utf8_try): assertion failed: (srcleft<= CHARSET_MAX_PENDING_BUF_SIZE) >> >> OS: FreeBSD 10.2 >>

Nick Rosier schreef: > > Timo Sirainen wrote: >> On 05 Oct 2015, at 22:05, Nick Rosier<nick+dovecot at bunbun.be> wrote: >>> Hi, >>> >>> one of my mailboxes returns following error when I run doveadm index on it: >>> >>> Panic: file charset-iconv.c: line 85 (charset_to_utf8_try): assertion failed: (srcleft<=

Hey, I'm getting messages exited on signal 6 (core dumped) when doing imap command "a UID SORT (DATE) UTF-8 BODY someword" message log file Jan 26 13:57:20 mail dovecot: imap(kristjan.eentsalu at yyy.yy): Panic: file charset-iconv.c: line 87 (charset_to_utf8_try): assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE) Jan 26 13:57:20 mail dovecot: imap(kristjan.eentsalu at

Set up fts_xapian over the weekend and re-indexed. https://github.com/grosjo/fts-xapian Tried to search my INBOX and got: > dovecot: indexer-worker: Panic: file charset-iconv.c: line 83 (charset_to_utf8_try): assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE) What could I possibly have lurking in my INBOX to cause that ?? -- Yarema

On 16 Oct 2015, at 23:44, Nick Rosier <nick+dovecot at bunbun.be> wrote: > > >> gdb --args doveadm index -u user at domain INBOX >> run >> <it should crash now> >> f 5 >> p src >> p ic_srcbuf >> p *src_size >> p srcleft > I recompiled Dovecot with Debug but I suspect I will have to do it for all the required libraries as well;

hi everyone I realise this not exactly on topic, I'm hoping an expert or two could confirm that following is not caused somehow by samba: I try xfreerdp to connect to a Win10 which is a member of NT-style domain and it fails this way: [14:55:33:905] [8048:8055] [ERROR][com.freerdp.core.nla] - SPNEGO failed with NTSTATUS: 0xC0000017 [14:55:33:905] [8048:8055] [ERROR][com.freerdp.core] -

On Thu, 2023-08-10 at 20:56 +0200, Fabio Muzzi via samba wrote: > On 10/08/2023 17.52, Philippe LeCavalier via samba wrote: > > > The solution is to update Samba to (security update to 4.17) so > > that 166 > > (and possible 244) work from the client side. If you rely on a > > client side > > solution you will likely continuously revisit this issue. > >

13.07.2023 19:17, Adi Kriegisch wrote: > Hi! > >> I was looking at the code this morning trying to figure out how to >> reject packet with lvl2 properly, - unfortunately I don't know samba >> well enough to be able to find the place "quickly" and I got distracted >> by other things. It was my first thought when someone posted the debug >> info

Hello, The other day Justin Peter presented a mini program to plot a topographic map with an overlay of the worldHires. I seemed interesting so I checked the ETOPO5 site and find that there is a new file ETOPO1 with a 1 minute grid. I downloaded it and tried a similar procedure. Now the ETOPO1.gz is 1 Gb and the uncompressed file is 5 Gb. They do not fit into my laptop. I tried the following

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it: