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, "/dovecot-shared", NULL),
> &st) == 0) {
>
> Might be a false alarm, but might be worth checking out anyway.I don't see how that code could be broken. It also goes fine through valgrind. > 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 behaviour in the future > when time_t values won't fit inside 32 bits ints :-) It'll fit for the next 97 years. And I doubt it'll be a problem then anymore. > 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 the same > assumptions in that case :-) That is interesting.. I don't think I'm doing anything wrong there though. I'll see if I can reproduce this and then try to reduce the test case needed to catch this and then ask gcc people if it's really a bug.
signature.asc
Description: This is a digitally signed message part
