caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* AMD64 segfault
@ 2005-05-12 22:35 skaller
  2005-05-13  1:33 ` [Caml-list] " Jon Harrop
  2005-05-13  8:14 ` skaller
  0 siblings, 2 replies; 5+ messages in thread
From: skaller @ 2005-05-12 22:35 UTC (permalink / raw)
  To: caml-list

I just built caml 3.08.3 on my new AMD64 and compiled and ran the usual
hello world with ocamlopt.opt, however the Felix compiler segfaults.
The bytecode version runs fine.  Felix uses bignums and unix, otherwise
it is a pure ocaml program (no 3pl C libraries).

I have no idea where start looking. I'm running Ubuntu (Hoary) 
and using gcc 3.4.

Any hints?


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] AMD64 segfault
  2005-05-12 22:35 AMD64 segfault skaller
@ 2005-05-13  1:33 ` Jon Harrop
  2005-05-14  4:14   ` skaller
  2005-05-13  8:14 ` skaller
  1 sibling, 1 reply; 5+ messages in thread
From: Jon Harrop @ 2005-05-13  1:33 UTC (permalink / raw)
  To: caml-list

On Thursday 12 May 2005 23:35, skaller wrote:
> I just built caml 3.08.3 on my new AMD64 and compiled and ran the usual
> hello world with ocamlopt.opt, however the Felix compiler segfaults.
> The bytecode version runs fine.  Felix uses bignums and unix, otherwise
> it is a pure ocaml program (no 3pl C libraries).
>
> I have no idea where start looking. I'm running Ubuntu (Hoary)
> and using gcc 3.4.
>
> Any hints?

Yes, the stack overflows much more quickly on AMD64 for me (pure64 Debian vs 
stock x86 Debian) and also causes a segfault instead of throwing 
Stack_overflow. I've no idea why.

Try playing with ulimit to set the stack size and rerunning your program.

I have found no other sources of segfaults with OCaml on AMD64.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] AMD64 segfault
  2005-05-12 22:35 AMD64 segfault skaller
  2005-05-13  1:33 ` [Caml-list] " Jon Harrop
@ 2005-05-13  8:14 ` skaller
  1 sibling, 0 replies; 5+ messages in thread
From: skaller @ 2005-05-13  8:14 UTC (permalink / raw)
  To: caml-list

On Fri, 2005-05-13 at 08:35, skaller wrote:
> I just built caml 3.08.3 on my new AMD64 and compiled and ran the usual
> hello world with ocamlopt.opt, however the Felix compiler segfaults.
> The bytecode version runs fine.  Felix uses bignums and unix, otherwise
> it is a pure ocaml program (no 3pl C libraries).
> 
> I have no idea where start looking. I'm running Ubuntu (Hoary) 
> and using gcc 3.4.
> 
> Any hints?

I have found the error occurs in a particular part of the
program -- the instantiator, which takes a generic entity
and instantiates it ..

I added a debugging print in an attempt to 'binary chop'
to the line with the error.. unfortunately that magically
fixes the problem.

Using gdb I get a message saying the SIGSEGV is in caml_apply5().
Anyone know what that is doing?

More fiddling indicates the problem occurs in the code below.

1. As written it crashes.

2. uncommenting the 'processing exe' does not fix the problem,
the diagnostic is not emitted before the segfault

3. uncommenting "doing exes", the diagnost IS printed before
the segfault

4. uncommenting "Process function" the segfault doesn't occur 
at all

Note that 'process_function' is just a forwarding
function that forgets some arguments ..

-------------------------------------
and process_exes syms bbdfns ref_insts1 ts hvarmap exes = 
  print_endline "Doing exes";
  iter (process_exe syms bbdfns ref_insts1 ts hvarmap) exes
-----------------------------------------------------

Full code below from 'src.flx_inst.ml" in Felix version 1.0.23

----------------------------------------------------------------
and process_exe syms bbdfns ref_insts1 ts hvarmap (exe:bexe_t) =
  let ue sr e = process_expr syms bbdfns ref_insts1 hvarmap sr e in
  let uis i ts = add_inst syms ref_insts1 (i,ts) in
  let ui i = uis i ts in
  (*
  print_endline ("processing exe " ^ string_of_bexe syms.dfns 0 exe);
  *)
  match exe with
.... elided ........  
    -> ()

and process_exes syms bbdfns ref_insts1 ts hvarmap exes = 
  print_endline "Doing exes";
  iter (process_exe syms bbdfns ref_insts1 ts hvarmap) exes

and process_function syms bbdfns hvarmap ref_insts1 index sr argtypes
ret exes ts =
  (*
  print_endline ("Process function " ^ si index);
  *)
  process_exes syms bbdfns ref_insts1 ts hvarmap exes 



-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] AMD64 segfault
  2005-05-13  1:33 ` [Caml-list] " Jon Harrop
@ 2005-05-14  4:14   ` skaller
  2005-05-14 13:29     ` Jon Harrop
  0 siblings, 1 reply; 5+ messages in thread
From: skaller @ 2005-05-14  4:14 UTC (permalink / raw)
  To: Jon Harrop; +Cc: caml-list

On Fri, 2005-05-13 at 11:33, Jon Harrop wrote:
> On Thursday 12 May 2005 23:35, skaller wrote:
[]
> Yes, the stack overflows much more quickly on AMD64 for me (pure64 Debian vs 
> stock x86 Debian) and also causes a segfault instead of throwing 
> Stack_overflow. I've no idea why.

Addresses are 64 bits instead of 32 .

> Try playing with ulimit to set the stack size and rerunning your program.

My ulimit is 8192, or 8Meg -- same as my 32 bit machine which
is a bit strange -- but it seems reasonable to me.

I tried 16M but it doesn't make any noticable difference.

I would suspect the stack size if the program processes smaller
files but failed on larger more complex ones, but that doesn't
seem to be the case. The fault now appears isolated to a single
function call, which suggests the Ocamlopt back end 
code generator, particularly as introducing a diagnostic
sometimes fixes the problem (which would also cause a different
instruction sequence to be generated). OTOH a lot of functions
get called apparently without error before this point in the 
program is reached, so perhaps not.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] AMD64 segfault
  2005-05-14  4:14   ` skaller
@ 2005-05-14 13:29     ` Jon Harrop
  0 siblings, 0 replies; 5+ messages in thread
From: Jon Harrop @ 2005-05-14 13:29 UTC (permalink / raw)
  To: caml-list

On Saturday 14 May 2005 05:14, skaller wrote:
> On Fri, 2005-05-13 at 11:33, Jon Harrop wrote:
> > Yes, the stack overflows much more quickly on AMD64 for me (pure64 Debian
> > vs stock x86 Debian) and also causes a segfault instead of throwing
> > Stack_overflow. I've no idea why.
>
> Addresses are 64 bits instead of 32.

That doesn't explain why it segfaults rather than throwing Stack_overflow.

Also, does ocamlopt put non-address data on the stack (e.g. floats)?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-05-14 13:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-12 22:35 AMD64 segfault skaller
2005-05-13  1:33 ` [Caml-list] " Jon Harrop
2005-05-14  4:14   ` skaller
2005-05-14 13:29     ` Jon Harrop
2005-05-13  8:14 ` skaller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).