Erlang on FreeBSD/amd64

Benno Rice benno@REDACTED
Thu Feb 17 14:14:13 CET 2005


Brian Buchanan wrote:
>>I tried following your suggestions but I wasn't able to work out how to
>>modify the bootstrap versions.  I assume I'd need to recompile them
>>somehow?  Editing the .erl files containing scan_toks/2 doesn't appear
>>to get me any extra debug output.
> 
> 
> You have to recompile the .erl files using a working erlc (I used a
> FreeBSD/i386 machine and copied the .beam files over).  Put the
> replacement beam files in boostrap/lib/stdlib/ebin/ or where appropriate.

Ok, latest stage is that I've gotten as far as instrumenting size_object 
  in erts/emulator/beam/copy.c and discovered that at some point, when 
being called in the lead up to the following (caused by a segmentation 
fault):

#0  0x0000000000446049 in copy_struct (obj=13805914, sz=67108887,
     hpp=0x7fffffffd4c8, off_heap=0x7e2378) at beam/copy.c:419
#1  0x000000000044f45d in queue_monitor_message (p=0x7e2178, ref=8327066,
     type=15627, item=355, reason=34373646266) at beam/bif.c:318
#2  0x000000000046506e in doit_exit_monitor (mon=0x7f0f68,
     vpcontext=0x7fffffffd880) at beam/erl_process.c:1304
#3  0x00000000004b15d8 in erts_sweep_monitors (root=0x0,
     doit=0x464e00 <send_exit_message+320>, context=0x7fffffffd880)
     at beam/erl_monitors.c:692
#4  0x000000000046571c in do_exit (p=0x7e23b8, reason=34373646266)
     at beam/erl_process.c:1459
#5  0x00000000004c5254 in terminate_proc (c_p=0x7e23b8, Value=34373646266)
     at beam/beam_emu.c:4203
#6  0x00000000004c5000 in handle_error (c_p=0x7e23b8, pc=0x90dc68,
     reg=0x663080, bf=0x44ef40) at beam/beam_emu.c:4143
#7  0x00000000004bac31 in process_main () at beam/beam_emu.c:1961
#8  0x000000000042f5c5 in erl_start (argc=30, argv=0x7fffffffe020)
     at beam/erl_init.c:855
#9  0x000000000041a3a9 in main (argc=13907898, argv=0x4000017)
     at sys/unix/erl_main.c:28

that in size_object, I'm ending up with an object whose primary_tag is 
TAG_PRIMARY_BOXED but whose header value ends up being 0xffffffff.  Is 
this at all expected?  It appears to cause thing_arityval to return a 
bogus value but I'm not sure.  Am I on the right track here?  Or is 
there somewhere else I should look?

-- 
Benno Rice
benno@REDACTED
http://jeamland.net/



More information about the erlang-bugs mailing list