On Thu, 2008-09-11 at 15:13 +0200, Peter Eriksson wrote:
> Anyway, I've set up a small test case that tries to mimic the code in
> question (attached). Build with either of the following commands:
I simplified it further, attached. The interesting thing is that this
bug shows up only when destroy
>> Optimizer incorrectly assuming that it doesn't need to refetch
>> the variable value from the structure since it doesn't understand
>> that the i_stream_unref(&mail->data.stream) call actually modifies
>> the whole mail->data structure...
>>
>> Funny that both Gcc and Sun Studio seems to make th
Timo Sirainen escreveu:
> On Wed, 2008-09-10 at 15:46 +0200, Peter Eriksson wrote:
>
>> There seems to be a number of places in 'index-mail.c' that stores
>> 'time_t' values in 'uint32_t' variables.
>>
>> This might cause problems since 'time_t' is 64 bit on 64 bit Solaris
>> systems... (Definit
On Wed, 2008-09-10 at 15:46 +0200, Peter Eriksson wrote:
> > Attempting to read 4 bytes at address 0xffbff288
> > which is 216 bytes above the current stack pointer
> > stopped in maildir_open (optimized) at line 429 in file
> "maildir-storage.c"
> > 429 if (stat(t_strconcat(path, "/
Forgot to attach the dbx output... *Sigh*
Anyway, here it is.
- Peter
(dbx) cont
stopped in i_stream_unref (optimized) at line 20 in file "istream.c"
20 {
(dbx) print stream
stream = 0x100253a30
(dbx) print *stream
*stream = 0x1002b4290
(dbx) print **str
Peter Eriksson wrote:
> Another thing I just noticed (but you probably already is aware
> of that):
A last thing... I did some debugger tracing of the calls to
i_stream_unref and printed the arguments (see the attached file)
It seems the *stream in these two calls to i_stream_unref references t
Another thing I just noticed (but you probably already is aware
of that):
There seems to be a number of places in 'index-mail.c' that stores
'time_t' values in 'uint32_t' variables.
This might cause problems since 'time_t' is 64 bit on 64 bit Solaris
systems... (Definitely will cause some funny b
Some more debugging info that might be useful (or might not, but I
figure I'd include it here anyway):
I started the 'imap' process manually from withing Suns 'dbx'
debugger and enabled memory checking:
> setenv MAIL maildir:/home/peter/Maildir
> dbx /ifm/pkg/dovecot/1.1.3-cc-32-debug-opt/libexec
Timo Sirainen wrote:
> On Tue, 2008-09-09 at 13:23 +0200, Peter Eriksson wrote:
>> Maildir on NFS
>
> This is the first time I've heard this happening with maildir. It's
> always been with mboxes before.
>
>> IMAP process crashes for certain (many, but not all) users when
>> accessing certain f
Timo Sirainen skrev:
IMAP process crashes for certain (many, but not all) users when
accessing certain folders (in the example below, in crashes when
accessing my INBOX, about 1700 mails). I could access other
mailboxes without problems. And a simple telnet to the imap port
followed by a login
On Tue, 2008-09-09 at 13:23 +0200, Peter Eriksson wrote:
> Maildir on NFS
This is the first time I've heard this happening with maildir. It's
always been with mboxes before.
> IMAP process crashes for certain (many, but not all) users when
> accessing certain folders (in the example below, in cra
Dovecot 1.1.3
Solaris 10
SPARC (Sun Fire T1000)
Compiled with Sun Studio 12 compilers.
Maildir on NFS
Indexes on local disk (UFS).
'dovecot -n' output attached.
IMAP process crashes for certain (many, but not all) users when
accessing certain folders (in the example below, in crashes when
accessi
12 matches
Mail list logo
