Dmitri Sosnik | 1 Oct 03:33 2009
Picon

Re: 64-bit compile fails on Snow Leopard

I have no idea about autoconf, but I've checked logs and it looks like  
autoconf is using "uname -p" to get host architecture. Snow Leopard  
x64 returns i386 here.

Cheers,
D

On 01/10/2009, at 6:01 AM, Ryan Graham wrote:

> That's what I was trying to point out. It fails on the configure
> because it is looking for Darwin-i386 in the output from uname. The
> same check is done for each submodule as well. It should be a trivial
> fix, I just didn't have the time to make a patch for it.
>
> ~Ryan
>
> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik <dimavs <at> gmail.com>  
> wrote:
>> Thanks!
>>
>> But I've realised that it's an another problem. Configure detects  
>> wrong
>> architecture:
>>
>> checking build system type... i386-apple-darwin10.0.0
>> checking host system type... i386-apple-darwin10.0.0
>>
>> $uname -a
>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31  
>> 22:46:25
(Continue reading)

Ryan Graham | 1 Oct 06:20 2009
Picon

Re: 64-bit compile fails on Snow Leopard

Reboot and hold down the 6 and 4 keys on your keyboard. If your mac  
has a new enough CPU, it will boot up with the 64-bit kernel instead  
of the standard 32-bit kernel. The bug I'm reporting wouldn't  
typically be seen in normal use, but it is still wrong to assume non- 
i386 means ppc, which is what the check is probably there for.

~Ryan

On 2009-09-30, at 6:33 PM, Dmitri Sosnik <dimavs <at> gmail.com> wrote:

> I have no idea about autoconf, but I've checked logs and it looks  
> like autoconf is using "uname -p" to get host architecture. Snow  
> Leopard x64 returns i386 here.
>
> Cheers,
> D
>
>
>
> On 01/10/2009, at 6:01 AM, Ryan Graham wrote:
>
>> That's what I was trying to point out. It fails on the configure
>> because it is looking for Darwin-i386 in the output from uname. The
>> same check is done for each submodule as well. It should be a trivial
>> fix, I just didn't have the time to make a patch for it.
>>
>> ~Ryan
>>
>> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik <dimavs <at> gmail.com>  
>> wrote:
(Continue reading)

Dmitri Sosnik | 1 Oct 07:17 2009
Picon

Re: 64-bit compile fails on Snow Leopard

I am already booted with x64 kernel and conf.log says:

uname -m = x86_64
uname -r = 10.0.0
uname -s = Darwin
uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009;  
root:xnu-1456.1.25~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = Mach kernel version:
      Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009;  
root:xnu-1456.1.25~1/RELEASE_X86_64

configure:1358: checking build system type
configure:1376: result: i386-apple-darwin10.0.0
configure:1384: checking host system type
configure:1398: result: i386-apple-darwin10.0.0

Cheers,
D

On 01/10/2009, at 2:20 PM, Ryan Graham wrote:

> Reboot and hold down the 6 and 4 keys on your keyboard. If your mac  
> has a new enough CPU, it will boot up with the 64-bit kernel instead  
(Continue reading)

Ryan Graham | 1 Oct 19:53 2009
Picon

Re: 64-bit compile fails on Snow Leopard

My Mac died last night, but I downloaded the latest source (R13B02-1)
onto my Linux box at work...

$ grep -Inr "TMPSYS" ./
./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m`
./erts/configure.in:290:        if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./erts/configure:2782:TMPSYS=`uname -s`-`uname -m`
./erts/configure:2806:  if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./configure.in:210:TMPSYS=`uname -s`-`uname -m`
./configure.in:222:     if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
./configure:2691:TMPSYS=`uname -s`-`uname -m`
./configure:2705:       if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then

The configure scripts only allow the --enable-darwin-64bit switch if
you are running on the 32-bit kernel.

As your outputs show, if you boot up into the 64-bit kernel, `uname
-m` spits out x86_64 which results in the $TMPSYS being the string
"Darwin-x86_64", which the script fails to match against
"Darwin-i386". As a result, it prints out an error:

"$as_me:$LINENO: error: --enable-darwin-64bit only supported on x86 host"

~Ryan

On Wed, Sep 30, 2009 at 10:17 PM, Dmitri Sosnik <dimavs <at> gmail.com> wrote:
> I am already booted with x64 kernel and conf.log says:
>
(Continue reading)

Dan Gudmundsson | 2 Oct 09:52 2009
Picon
Picon

Re: 64-bit compile fails on Snow Leopard

We are aware of the problem, but have no machines that will boot with a 64-bit kernel,
and can't test it.

We will try to fix it in the next release.

/Dan

Ryan Graham wrote:
> My Mac died last night, but I downloaded the latest source (R13B02-1)
> onto my Linux box at work...
> 
> $ grep -Inr "TMPSYS" ./
> ./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m`
> ./erts/configure.in:290:        if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./erts/configure:2782:TMPSYS=`uname -s`-`uname -m`
> ./erts/configure:2806:  if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure.in:210:TMPSYS=`uname -s`-`uname -m`
> ./configure.in:222:     if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
> ./configure:2691:TMPSYS=`uname -s`-`uname -m`
> ./configure:2705:       if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
> 
> The configure scripts only allow the --enable-darwin-64bit switch if
> you are running on the 32-bit kernel.
> 
> As your outputs show, if you boot up into the 64-bit kernel, `uname
> -m` spits out x86_64 which results in the $TMPSYS being the string
> "Darwin-x86_64", which the script fails to match against
> "Darwin-i386". As a result, it prints out an error:
(Continue reading)

Dave Smith | 8 Oct 19:23 2009
Picon

beam crasher: ets + write_concurrency

Greetings,

I believe that I have identified a VM crasher when using ETS with
write concurrency enabled. Sample code is as follows:

T = ets:new(?MODULE, [{write_concurrency, true}]),
ets:insert_new(T, {foo, 1}),
ets:match(T, {nosuchvalue, '$1'}).

GDB stack trace shows:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
[Switching to process 69425]
0x00000001000c894b in db_select_chunk_hash (p=0x101466398,
tbl=0x1013b6eb0, pattern=4330115329, chunk_size=0, reverse=0,
ret=0x102185080) at beam/erl_db_hash.c:1426
1426		if (current->hvalue != INVALID_HASH &&
(gdb) bt
#0  0x00000001000c894b in db_select_chunk_hash (p=0x101466398,
tbl=0x1013b6eb0, pattern=4330115329, chunk_size=0, reverse=0,
ret=0x102185080) at beam/erl_db_hash.c:1426
#1  0x00000001000c85f2 in db_select_hash (p=0x101466398,
tbl=0x1013b6eb0, pattern=4330115329, reverse=0, ret=0x102185080) at
beam/erl_db_hash.c:1344
#2  0x00000001000b1c6f in ets_select_2 (A__p=0x101466398, A_1=262367,
A_2=4330115329) at beam/erl_db.c:2136
#3  0x00000001000b1524 in ets_match_2 (A__p=0x101466398, A_1=262367,
A_2=4335025986) at beam/erl_db.c:1940
#4  0x000000010011e5ed in process_main () at beam/beam_emu.c:2084
(Continue reading)

Sverker Eriksson | 9 Oct 10:34 2009
Picon
Picon

Re: [erlang-questions] beam crasher: ets + write_concurrency

Dave Smith wrote:
> I believe that I have identified a VM crasher when using ETS with
> write concurrency enabled. Sample code is as follows:
>
> T = ets:new(?MODULE, [{write_concurrency, true}]),
> ets:insert_new(T, {foo, 1}),
> ets:match(T, {nosuchvalue, '$1'})

Yes, it's repeatable on my machine as well (Linux x86_64, 64-bit VM).
I will have a look at it right now.

Thanks for reporting.
/Sverker, Erlang/OTP

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

Simon Cornish | 9 Oct 11:35 2009
Picon

R12B3 tracing crashes emulator

Tracing on [all], or specifically [running, scheduler_id] trashes the
stack leading to some sort of SEGV or BUS fault. Seen on Solaris
i386/64-bit and OS/X i386/32-bit.
This doesn't seem to be related to the other thing reported/fixed
recently in R13.
Patch attached.
Attachment (R12B-3-0F-ext.patch): application/octet-stream, 1124 bytes

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org
Björn-Egil Dahlberg | 11 Oct 18:45 2009
Picon
Picon

Re: R12B3 tracing crashes emulator

Hi Simon,

These issues are fixed in R12B-4 and later. This section of code was 
completely revised in R12B-4, ticket OTP-7481.

Are you seeing this on later releases as well?

Regards,
Björn-Egil
Erlang/OTP

Simon Cornish wrote:
> Tracing on [all], or specifically [running, scheduler_id] trashes the
> stack leading to some sort of SEGV or BUS fault. Seen on Solaris
> i386/64-bit and OS/X i386/32-bit.
> This doesn't seem to be related to the other thing reported/fixed
> recently in R13.
> Patch attached.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org
(Continue reading)

Adam Lindberg | 14 Oct 10:57 2009

Edoc crash when using macro with function

Hi!

Running edoc:file/1 on test.erl with this content will result in a crash in edoc:

-module(test).

-export([f/0]).

-define(FUNC, f() -> ok).

?FUNC.

Seems edoc in R13B02 can't handle the macro on line 7.

1> edoc:file("test.erl"). test.erl: at line 7: syntax error before: '.'
** exception exit: error
     in function  edoc:'-check_forms/2-fun-0-'/2
     in call from lists:foreach/2
     in call from edoc:read_source/2
     in call from edoc_extract:source/3
     in call from edoc:read/2
     in call from edoc:file/2

Cheers,
Adam

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

(Continue reading)


Gmane