Ethereal-dev: Re: [Ethereal-dev] Crash Opening Preferences under Fedora Core 4 AMD64

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Erwin Rol <mailinglists@xxxxxxxxxxxx>
Date: Fri, 03 Mar 2006 13:04:37 +0100
On Fri, 2006-03-03 at 09:36 +0800, Jeff Morriss wrote:

> Looks like there's a bug open for this:
> 
> http://bugs.ethereal.com/bugzilla/show_bug.cgi?id=784

I am seeing the same assert, and i believe this is a int->pointer
conversion problem on 64bit systems. 

The emem.c file has the following code;

/* Align our guard pages on page-sized boundaries */
prot1 = (char *) ((((int) npc->buf + pagesize - 1) / pagesize) * pagesize);
prot2 = (char *) ((((int) buf_end - (1 * pagesize)) / pagesize) * pagesize);
ret = mprotect(prot1, pagesize, PROT_NONE);
g_assert(ret != -1);
ret = mprotect(prot2, pagesize, PROT_NONE);
g_assert(ret != -1);

The (int) cast makes the size 32bit, than that 32bit value gets cast
back to a 64bit pointer. If the original npc-buf was above a "32bit" the
resulting pointer will be junk. And since newer systems randomize their
address space it might just be a coincidence that this code sometimes
works. 

Changing the (int) to (long) fixed the problem on my AMD64 system, but
(long) might also not always be the same size as a (char*). The stdint.h
man page mentions a intptr_t and uintptr_t, but i don't know if those
are available on all Ethereal-target platforms.

BTW I see more GCC warnings about wrong signs and int<->pointer wrong
size conversions, these might all case serious problems on 64bit systems
(most are inside dissectors, so they are unlikely to be found by trail
and error). 

- Erwin