Re: FreeBSD/amd64: bootstrap & memory allocation troubles

[Giorgos Keramidas]

On 2006-01-13 21:18, Giorgos Keramidas <address@hidden> wrote:
> address@hidden:/home/keramida/ws/cvs-emacs/emacs$ gdb src/bootstrap-emacs 
> lisp/bootstrap-emacs.core
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> Core was generated by `bootstrap-emacs'.
> [...]
> #0  allocate_string_data (s=0x179d380, nchars=50, nbytes=50) at alloc.c:1981
> 1981      s->data[nbytes] = '\0';
> (gdb) bt
> #0  allocate_string_data (s=0x179d380, nchars=50, nbytes=50) at alloc.c:1981
> #1  0x00000000004abc40 in make_uninit_multibyte_string (nchars=50, nbytes=50) 
> at alloc.c:2448
> #2  0x00000000004abd7d in make_specified_string (contents=0x7fffffff9380 
> "/home/keramida/ws/cvs-emacs/emacs/lisp/loaddefs.el",
>     nchars=0, nbytes=50, multibyte=0) at alloc.c:2401
> #3  0x0000000000486afd in Fexpand_file_name (name=140737488327552, 
> default_directory=25813859) at fileio.c:1709
> [...]
> (gdb) p s
> $1 = (struct Lisp_String *) 0x179d380
> (gdb) p *s
> $2 = {size = 50, size_byte = 50, intervals = 0x0, data = 0x1e99fd8 ""}
> (gdb) p nbytes
> $3 = 50
> (gdb) p s->data
> $4 = (unsigned char *) 0x1e99fd8 ""
> (gdb) p *(s->data)
> $5 = 0 '\0'
> (gdb) p *(s->data)@20
> $6 = '\0' <repeats 19 times>
> (gdb) p *(s->data)@50
> Cannot access memory at address 0x1e99fd8
> (gdb) p *(s->data)@49
> Cannot access memory at address 0x1e99fd8
> (gdb) p *(s->data)@40
> $7 = '\0' <repeats 39 times>
> (gdb) p *(s->data)@41
> Cannot access memory at address 0x1e99fd8
> (gdb) quit
> address@hidden:/home/keramida/ws/cvs-emacs/emacs$

As an added data-point while I continue tracking this, I fixed a bug in
the irssi IRC client last night that would similarly end up accessing
memory areas that are ``inaccessible''.

The new malloc() in FreeBSD may use mmap() to map allocated regions in
the virtual address space of the process, which some times ends up using
addresses above 4 GB.  These addresses cannot fit in an `int' anymore,
which means that if a function is supposed to return a pointer and it's
called from another source file without access to a proper prototype,
then the default return type of `int' assigned to it by GCC cause a
conversion (char *) -> int -> (char *).  The first conversion to `int'
truncates the high bits of teh address, which *are* significant, causing
addresses like 0x80123456 to end up being returned as 0x123456, which
triggers the core dump.

I think somewhere along the stack trace shown in the original message of
this thread something similar happens, but I'll post again when I find
out where this happens.