[erlang-questions] fprof module loading problem on R12B-1 [was: Binary pattern matching inconsistencies with R12B]

[Rory Byrne]

On Mon, Mar 03, 2008 at 10:01:49PM +0100, Rory Byrne wrote:
> 
> Just applied the patch and everything works great now. Many thanks Bjorn!
> 

Hello,

I'm seeing some problems with fprof on i386 (but not on amd64).
I'm not certain that the problem is related to this thread but 
I think it might be since it's the same code that is effected.

Basically, fprof dies when it tries to load certain modules. It's
not just my own modules that causes this - here's what happens
when running fprof on http:request/1 on my machine:


%% -- START CODE -- %%

Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] 
[kernel-poll:false]

Eshell V5.6  (abort with ^G)
1> inets:start().
ok
2> fprof:apply(http, request, ["http://www.erlang.com"]).
Aborted

%% -- END -- %%


>From what I have seen, the modules that are effected can
only be profiled sucessfully if you load the module and its
dependencies before running fprof. The code that I posted
at the start of this thread (weird.erl and scanner.erl) is 
effected by this problem so I'll use weird.erl in the 
following examples:


%% -- START CODE -- %%

$ erl
Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] 
[kernel-poll:false]

Eshell V5.6  (abort with ^G)
1> l(weird).
{module,weird}
2> fprof:apply(weird, run, [1]).
ok
3> fprof:apply(weird, run, [1]).
ok
4> q().
ok

$ erl
Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] 
[kernel-poll:false]

Eshell V5.6  (abort with ^G)
1> fprof:apply(weird, run, [1]).
Aborted

%% -- END -- %%


Also, there is no weird:run/3, but I get the same result if I ask
fprof to call it:


%% -- START CODE -- %%

$ erl
Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] 
[kernel-poll:false]

Eshell V5.6  (abort with ^G)
1> fprof:apply(weird, run, [what, the, f]).	
Aborted

%% -- END -- %%


Hipe is not supported on my i386 so I can't test with it.

This isn't really a problem for me as I can make warm-up
calls to my modules before profiling - probably a smart 
thing to do anyway. Just thought it might be of interest.
 
Cheers.

Rory