ocaml sefault in bytecode: unanswered questions

ocaml sefault in bytecode: unanswered questions

[ivan chollet]

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

Hello guys,

 

I would like to ask a question about ocaml error handling. Actually many
questions that I've never dared asking on the official mailing list. I've
had a few problems sparsely with OCaml bytecode programs throwing a core
dump. When analyzing these core dumps, gdb says it's a "Segmentation fault".
Here is an example of this:

 

This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols
found)...

Core was generated by `ocamlrun'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.

Loaded symbols for /lib/libm.so.5

Reading symbols from /lib/libncurses.so.7...(no debugging symbols
found)...done.

Loaded symbols for /lib/libncurses.so.7

Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.

Loaded symbols for /lib/libc.so.7

Reading symbols from /usr/local/lib/ocaml/stublibs/dllunix.so...(no
debugging symbols found)...done.

Loaded symbols for /usr/local/lib/ocaml/stublibs/dllunix.so

Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.

Loaded symbols for /libexec/ld-elf.so.1

#0  0x080606de in caml_interprete ()

 

Not very informative. So here are my questions:

 

-          What is the best way to produce and analyze core dumps in ocaml?
Should I compile in bytecode or native? Is there any special gdb "trick"
that gives you more information? Is there any special "trick" while
compiling the ocaml runtime to make it throw more information?

-          Then, my main question is actually: in bytecode, what can produce
segfaults? My ocaml code is completely standard, excepted that I use the
Marshal module. So my question is rather: outside the Marshal module, what
can cause segfault?

-          Slightly unrelated question: I have been able to generate
segfaults by running ocaml code that: 1) iterates recursively through a list
reference 2) changes the reference while still iterating on it. For example,
you just do a "List.iter myfun !myref", and within the function myfun, you
do stuff like "myref := List.filter somefilterfunction !myref". It is not
good to program like this, but for some reason I thought ocaml would not
segfault on that. Is this expected behavior? If it's not, I'll be happy to
provide some simple source code that illustrates it. (nevermind I have
actually cleaned all my code base from these dirty uses of references)

-          About ocaml bytecode interpreter and ocaml native compiler: it
seems to me, looking at the ocaml source tree, that these two parts are
completely unrelated (I'm talking about the byterun and the asmrun/asmcomp
directories), meaning that they don't share any source code. Is that
correct? 

 

Anyway guys, thanks for reading this, if you did, don't know if this makes
any sense to you.


[-- Attachment #2: Type: text/html, Size: 8238 bytes --]

Re: ocaml sefault in bytecode: unanswered questions

[Sylvain Le Gall]

On 08-08-2009, ivan chollet <ivan.chollet@free.fr> wrote:
>
> Yes it was a freebsd 6.4 with ocaml 3.10.2
>

OCaml version is quite old, but should be ok.

> I'll run the program on linux later and see how it goes.
>
>  
>
> Thanks for your advices regarding debugging. I pretty much tried all of
> these though. the thing is my error is not an ocaml error at runtime but an
> error of the ocaml runtime. And to analyze a core dump of ocamlrun, I just
> thought my best bet was gdb. Whatever.
>
>  
>
> OK I'll try to provide you with a minimal ocaml code that produce an
> ocamlrun error. Might take a little while as I'm not free.
>
> In the meantime, I've got a newbie question regarding ocaml garbage
> collector and the same List.iter stuff:
>
> Say you do a "List.iter myfun !myref", where !myref is a list (hehe.), and
> where myfun is a function that does reallocations of myref (that is
> affectations like myref := [some new or old objects]). The pointers myref
> that are generated through this process are destroyed each time a new
> reallocation of myref is done. Of course the underlying linked lists that
> are not referenced anymore shouldn't be collected by the GC before the end
> of the main "List.iter", otherwise it's iterating through a linked list that
> has been garbage collected.
>
> My question is: does the GC know that it cannot collect the unreferenced
> myref pointers before the end of the List.iter? 
>


Why "the underlying linked lists that not referenced anymore shouldn't
be collected by the GC before the end the main "List.iter"" ?

OCaml list are single-linked list, whenever you cannot access the head
of the list everything until the current element can be GCed.

Here is the implementation of List.iter

let rec iter f = function
    [] -> ()
  | a::l -> f a; iter f l

As soon as you apply "myfun" to "a", the reference to a is not used so
it can be collected by the GC if there is no more reference to it.

I think the GC CAN collect the unreferenced myref pointers before the
end of the List.iter...

Regards
Sylvain Le Gall

Re: ocaml sefault in bytecode: unanswered questions

[ivan chollet]

[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]

Yes it was a freebsd 6.4 with ocaml 3.10.2

I'll run the program on linux later and see how it goes.

 

Thanks for your advices regarding debugging. I pretty much tried all of
these though. the thing is my error is not an ocaml error at runtime but an
error of the ocaml runtime. And to analyze a core dump of ocamlrun, I just
thought my best bet was gdb. Whatever.

 

OK I'll try to provide you with a minimal ocaml code that produce an
ocamlrun error. Might take a little while as I'm not free.

In the meantime, I've got a newbie question regarding ocaml garbage
collector and the same List.iter stuff:

Say you do a "List.iter myfun !myref", where !myref is a list (hehe.), and
where myfun is a function that does reallocations of myref (that is
affectations like myref := [some new or old objects]). The pointers myref
that are generated through this process are destroyed each time a new
reallocation of myref is done. Of course the underlying linked lists that
are not referenced anymore shouldn't be collected by the GC before the end
of the main "List.iter", otherwise it's iterating through a linked list that
has been garbage collected.

My question is: does the GC know that it cannot collect the unreferenced
myref pointers before the end of the List.iter? 

Sorry, I just wanted to ask this question to rule it out.

 

Thanks again.

 

 

 

 

On 07-08-2009, ivan chollet <ivan.chollet@free.fr> wrote:

> 

> This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols

> found)...

> 

> Not very informative. So here are my questions:

 

I suppose you are running freebsd ? Which version of freebsd, of ocaml ? 

 

> 

>  

> 

> -          What is the best way to produce and analyze core dumps in
ocaml?

> Should I compile in bytecode or native? Is there any special gdb "trick"

> that gives you more information? Is there any special "trick" while

> compiling the ocaml runtime to make it throw more information?

> 

 

gdb is not the perfect tool to debug ocaml program. You should give a

try to ocamldebug which is a better option for bytecode (see below for

options). Bytecode is more informative when coming to reporting

backtrace (at least with old version of ocaml). 

 

Compile every program with "-g" option (just like gcc). 

 

If you have compiled everything with "-g" option, you can also use the

environment variable OCAMLRUNPARAM="b" to get a backtrace for your

exception, at runtime.

 

> -          Then, my main question is actually: in bytecode, what can
produce

> segfaults? My ocaml code is completely standard, excepted that I use the

> Marshal module. So my question is rather: outside the Marshal module, what

> can cause segfault?

 

Some part of the bytecode are just standard C, everything can cause a

segfault just as C. These errors are not very common but it is possible

that some case are not well handled on freebsd. Most probably a porting

issue.

 

Marshal module can easily trigger a segfault when you map the loaded data

to a type which doesn't match the dumped data.

 

Example: 

List.length (Marshal.from_string (Marshal.to_string 1234 []) 0);;

 

Here the integer value is marshalled and then unmarshalled as a list ->

segfault.

 

> 

> -          Slightly unrelated question: I have been able to generate

> segfaults by running ocaml code that: 1) iterates recursively through a
list

> reference 2) changes the reference while still iterating on it. For
example,

> you just do a "List.iter myfun !myref", and within the function myfun, you

> do stuff like "myref := List.filter somefilterfunction !myref". It is not

> good to program like this, but for some reason I thought ocaml would not

> segfault on that. Is this expected behavior? If it's not, I'll be happy to

> provide some simple source code that illustrates it. (nevermind I have

> actually cleaned all my code base from these dirty uses of references)

> 

 

Could you provide a minimal example code for this error ? I don't think

this should generate a segfault.

 

 

Regards

Sylvain Le Gall

 


[-- Attachment #2: Type: text/html, Size: 15865 bytes --]

Re: ocaml sefault in bytecode: unanswered questions

[Sylvain Le Gall]

On 07-08-2009, ivan chollet <ivan.chollet@free.fr> wrote:
>
> This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols
> found)...
>
> Not very informative. So here are my questions:

I suppose you are running freebsd ? Which version of freebsd, of ocaml ? 

>
>  
>
> -          What is the best way to produce and analyze core dumps in ocaml?
> Should I compile in bytecode or native? Is there any special gdb "trick"
> that gives you more information? Is there any special "trick" while
> compiling the ocaml runtime to make it throw more information?
>

gdb is not the perfect tool to debug ocaml program. You should give a
try to ocamldebug which is a better option for bytecode (see below for
options). Bytecode is more informative when coming to reporting
backtrace (at least with old version of ocaml). 

Compile every program with "-g" option (just like gcc). 

If you have compiled everything with "-g" option, you can also use the
environment variable OCAMLRUNPARAM="b" to get a backtrace for your
exception, at runtime.

> -          Then, my main question is actually: in bytecode, what can produce
> segfaults? My ocaml code is completely standard, excepted that I use the
> Marshal module. So my question is rather: outside the Marshal module, what
> can cause segfault?

Some part of the bytecode are just standard C, everything can cause a
segfault just as C. These errors are not very common but it is possible
that some case are not well handled on freebsd. Most probably a porting
issue.

Marshal module can easily trigger a segfault when you map the loaded data
to a type which doesn't match the dumped data.

Example: 
List.length (Marshal.from_string (Marshal.to_string 1234 []) 0);;

Here the integer value is marshalled and then unmarshalled as a list ->
segfault.

>
> -          Slightly unrelated question: I have been able to generate
> segfaults by running ocaml code that: 1) iterates recursively through a list
> reference 2) changes the reference while still iterating on it. For example,
> you just do a "List.iter myfun !myref", and within the function myfun, you
> do stuff like "myref := List.filter somefilterfunction !myref". It is not
> good to program like this, but for some reason I thought ocaml would not
> segfault on that. Is this expected behavior? If it's not, I'll be happy to
> provide some simple source code that illustrates it. (nevermind I have
> actually cleaned all my code base from these dirty uses of references)
>

Could you provide a minimal example code for this error ? I don't think
this should generate a segfault.


Regards
Sylvain Le Gall