hipe segmentation fault

[Mikael Pettersson]

Date: Mon, 03 Apr 2006 10:30:15 -0400, Serge Aleynikov wrote:
> Ops...  Sorry, this test case was taken from Rickard Green's post on 
> profiling P11B smp scheduling support.  I wanted to run it on multi-cpu 
> host, and installed R10B-10 and P11B releases with and without hipe.
...
> Erlang (BEAM) emulator version 5.4.13 [source] [hipe] [threads:0]
> 
> Eshell V5.4.13  (abort with ^G)
> 1> c(big, [native]).
> {ok,big}
> 2> big:bang(4).
> Segmentation fault (core dumped)
...
> (gdb) bt
> #0  0x08aae41c in ?? ()
> #1  0x080f0f63 in x86_call_to_native () at hipe/hipe_x86_glue.S:42
> #2  0x00000000 in ?? ()
> (gdb)
> 
> ...
> 
> Looking at hipe_x86_glue.S:42:
> 
> x86_call_to_native:
>      ENTER_FROM_C
>      /* get argument registers */
>      LOAD_ARG_REGS
>      /* call the target */
>      NSP_CALL(*P_NCALLEE(P))  <-- Failing here
> 
> I'm not sure what this call does, but maybe Mikael can give a clue.

This is the entry point for BEAM calling a native-compiled function.
NSP_CALL() currently expands to a plain "call" instruction; it's a macro so
we can experiment with and measure other ways of performing calls and returns.

I'm unable to reproduce your problem here. The closest machine we
have to yours is a dual HT P4 Xeon of the older 32-bit only type,
running FC4 user-space on a custom 2.6.9-34 RHEL4 kernel, and things
just work. Your test case also works on an Athlon64 running the same
FC4/RHEL4 combo in pure 64-bit mode.

It would help if you could run beam from gdb (easiest is to attach to
it, otherwise you have to set up several environment variables), and
print the exact location of the program counter at the crash, list the
surrounding assembler code, print the registers, and also the print the
contents of "P" (print *p in a C frame, print *(Process*)$ebp ought to
do the same in assembler mode).

/Mikael