Displaying 20 results from an estimated 400 matches similar to: "assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)"
2018 Dec 21
2
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
> > #
2019 Jan 21
2
assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
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?
>
2019 Feb 11
1
assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
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?
2018 Dec 21
0
assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
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
2019 Jan 20
0
assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
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,
2019 Feb 09
0
assertion failed: (srcleft <= CHARSET_MAX_PENDING_BUF_SIZE)
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
2015 Oct 05
4
doveadm index assertion failed
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
2015 Oct 16
0
doveadm index assertion failed
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
>>
2015 Oct 16
0
doveadm index assertion failed
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<=
2018 Jan 26
1
exited on signal 6 (core dumped) when searching folder
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
2019 Nov 11
1
FTS indexer-worker Panic
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
2015 Oct 17
2
doveadm index assertion failed
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;
2018 Feb 22
4
xfreerdp and SPNEGO failed
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] -
2023 Aug 10
1
KB5029244...
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.
>
>
2023 Jul 13
1
ComputerSecureChannel -Verbose False since windows 10/11 update 07/2023
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
2010 Aug 02
1
read the middle of a file
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
2008 Jul 08
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
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?
>
>
2008 Jul 11
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
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
2008 Jul 10
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
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
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
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: