dovecot - Dec 2004 - IMAP crashes with signal 10 (SIGBUS)

Any idea on what's causing this?

Description:
 	imap process crashed with SIGBUS.

Versions:
 	OS: Solaris 8, 9
 	Dovecot: 1.0-test57
 	Gcc: 3.2

Configure options:
 	env CC=gcc CFLAGS="-O -g" ./configure \
 		--prefix=/var/dovecot \
 		--disable-ipv6 \
 		--with-ssl=openssl \
 		--with-ssldir=/etc/ssl \
 		--with-passwd-file \
 		--without-bsdauth \
 		--without-checkpassword \
 		--without-pam \
 		--without-passwd \
 		--without-shadow \
 		--without-vpopmail \
 		--without-static-userdb \
 		--without-libiconv-prefix \
 		--with-storages=mbox \
 		--with-pop3d

 	Interestingly, eliminating optimisation seems to get rid of the
 	problem, suggesting it might be a compiler problem.  I've also tried
 	gcc flags "-m32", "-m64", "-O3",
"-O2", "-O1" and configure options
 	"--with-file-offset-size=32 --with-mem-align=4" with no relief.

IMAP dialogue:
 	... deleted cache, just in case ...

 	>>
'MAIL=mbox:/nfs/ono/mail/:INBOX=/nfs/mail/ono:INDEX=/nfs/ono/dovecot/cache'
imap
 	<< * PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND
UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as ono

 	>> x1 SELECT INBOX
 	>> * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
 	>> * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
Flags permitted.
 	>> * 2 EXISTS
 	>> * 2 RECENT
 	>> * OK [UNSEEN 1] First unseen.
 	>> * OK [UIDVALIDITY 1102645397] UIDs valid
 	>> * OK [UIDNEXT 3] Predicted next UID
 	>> x1 OK [READ-WRITE] Select completed.

 	<< x2 FETCH 1:2 (ENVELOPE)
 	>> Bus Error - core dumped

INBOX content:
 	From abc at hushmail.com Thu Nov 18 18:04:46 2004
 	Received: from bogus.com ([221.15.172.119])
 		by mx.fake.com (8.12.10/8.12.10) with SMTP id iAJ24MIs000307;
 		Thu, 18 Nov 2004 18:04:30 -0800 (PST)
 	Message-ID: <81360434043.65276 at abc@hushmail.com>
 	From: <abc at hushmail.com>
 	To: <fake at fakeu.edu>
 	Subject: blah
 	Date: Thu, 18 Nov 2004 19:00:26 -0700
 	X-UID: 1

 	blah blah

 	From def at yahoo.com Thu Nov 18 18:48:37 2004
 	Received: from bogus.com (client-200.121.192.53.speedy.net.pe [200.121.192.53]
(may be forged))
 		by mx.fake.com (8.12.10/8.12.10) with SMTP id iAJ2mCIs001481
 		for <somebody at fakeu.edu>; Thu, 18 Nov 2004 18:48:32 -0800 (PST)
 	Message-Id: <200411190248.iAJ2mCIs001481 at blah.ca>
 	Date: Fri, 19 Nov 2004 02:39:36 +0000
 	From: <def at yahoo.com>
 	To: somebody at fakeu.edu
 	Subject: blah
 	X-UID: 2

 	blah blah

Backtrace:
 	#0  mbox_file_seek (ibox=0x8d9b0, view=0x8dc38, seq=2, deleted_r=0xffbef40c)
at mbox-file.c:119
 	#1  0x0002afbc in mbox_mail_seek (mail=0x935f0) at mbox-mail.c:48
 	#2  0x0002b1b0 in mbox_mail_get_stream (_mail=0x935f0, hdr_size=0x0,
body_size=0x0) at mbox-mail.c:159
 	#3  0x00034894 in index_mail_get_headers (_mail=0x935f0, _headers=0x93d80) at
index-mail-headers.c:540
 	#4  0x000343e4 in index_mail_headers_get_envelope (mail=0x935f0) at
index-mail-headers.c:362
 	#5  0x000334cc in index_mail_get_special (_mail=0x935f0,
field=MAIL_FETCH_IMAP_ENVELOPE)
 	    at index-mail.c:578
 	#6  0x0002b118 in mbox_mail_get_special (_mail=0x935f0,
field=MAIL_FETCH_IMAP_ENVELOPE)
 	    at mbox-mail.c:128
 	#7  0x00020c80 in fetch_envelope (ctx=0x881d8, mail=0x935f0, context=0x0) at
imap-fetch.c:347
 	#8  0x0002081c in imap_fetch (ctx=0x881d8) at imap-fetch.c:209
 	#9  0x0001c034 in cmd_fetch (client=0x83f50) at cmd-fetch.c:164
 	#10 0x0001f2a4 in client_handle_input (client=0x83f50) at client.c:324
 	#11 0x0001f370 in _client_input (context=0x83f50) at client.c:368
 	#12 0x000593b8 in io_loop_handler_run (ioloop=0x810c0) at ioloop-poll.c:184
 	#13 0x00058d34 in io_loop_run (ioloop=0x810c0) at ioloop.c:218
 	#14 0x000272c8 in main (argc=0, argv=0xffbefa4c, envp=0xffbefa5c) at
main.c:224

Joseph Tam <tam at math.ubc.ca>

On 14.12.2004, at 04:28, Joseph Tam wrote:
> Any idea on what's causing this?
>
> Description:
>  	imap process crashed with SIGBUS.
>
> Backtrace:
>  	#0  mbox_file_seek (ibox=0x8d9b0, view=0x8dc38, seq=2, 
> deleted_r=0xffbef40c) at mbox-file.c:119
..

It crashes because the returned data address isn't 64bit aligned. The 
code tries to do the alignmentation right, but I guess there's some bug 
in it. I'll try to look into this soon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20041215/1994db65/attachment-0001.bin>

I wrote:
> Any idea on what's causing this?
> 
> Description:
>  	imap process crashed with SIGBUS.
> 
> Versions:
>  	OS: Solaris 8, 9
>  	Dovecot: 1.0-test57
>  	Gcc: 3.2
 	same with 3.4.3
> 
> Backtrace:
>  	#0  mbox_file_seek (ibox=0x8d9b0, view=0x8dc38, seq=2,
deleted_r=0xffbef40c) at mbox-file.c:119
>	...
Subsequent versions still crashed and I looked into the problem further. 
Specifically it
crashes at this line

 	offset = *((const uint64_t *)data);

when "data" assumes a non-64 bit aligned value.  At first I thought
that 64-bit
ints should always be aligned on 64-bit boundaries, but when I isolated this
code
into a standalone executable to demonstrate it (no arguments to cause a crash,
one
argument is OK):

 	int main (int argc, char *argv[]) {
 		int		a[]={1,2,3,4};
 		long long int	i64;
 		void 		*p=(void *) (&a[argc]);;

 		printf("Pointer to 32-bit int = %x\n",p);
 		i64 = *((long long int *)p);
 		printf("Successful casting to 64-bit int: value=%016llx\n",i64);
 	}

I found out that the presence of any optimisation (-O, -O2, -O3) will cause this
to
crash, yet it will work if no optimisation is present even though a pointer
being cast
is still not aligned on a 64-bit boundary (but aligned on a 32-bit boundary).

I check the gcc bug web page page came up with this reference which may explain
this
behaviour.

 	http://gcc.gnu.org/bugs.html#known
 		- see section "Casting does not work as expected when optimization is
turned on"
 	http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html

They claim that this casting violates ISO aliasing rules and the results like
crashing are to be expected.  Maybe this statement ought to be rewritten

 	memcpy(&offset,data,sizeof(uint64_t));

There is one other statement at

 	mbox-synbc.c:319 (1.0-test59)

that may need this consideration.

Joseph Tam <tam at math.ubc.ca>