[Caml-list] OCaml 3.08 and Bus Errors

["David McClain" <dmcclain1@mindspring.com>]

... in going back over my sources from 5 years ago, it appears that at one
time I was trying (perhaps too hard) to outsmart the internals of OCaml. I
regret having to do this, but bear with me one moment...

I was avoiding declaring CAMLparamN() of input arguments in many cases
because I was attempting to gain a unified access to both of OCaml native
Arrays of double, and my own FastArray implementation which predates the
BigArray stuff. The only time it appeared necessary to declare an input
parameter is when some OCaml allocation could occur, and where we need to
track the possible relocation of those parameters as a result of a triggered
GC cycle.

But if I were completely finished accessing these parameters by the time an
OCaml allocation occurred, then I could care less where these parameters had
possibly been relocated. The caller of my C routines still have live
pointers to these parameters and so they form valid memory roots for GC.
Hence, GC does not need my CAMLparam's to find the system roots, it merely
offers through these macros to allow me to find them again should I need to
after some GC may have relocated them.

In my case with my FastArrays I dare not put them in these CAMLparam macros
because the arena pointer to the FastArray doubles array is not a valid
OCaml structure address, and so I don't want GC pounding on them. These
addresses are external to the OCaml heap, and so I guess OCaml would ignore
them anyway. I was playing fast and loose on purpose here because native
OCaml arrays of doubles do pass the address of their own arena. My C
routines have uniform access to the arena of both kinds of arrays.

I realized there is risk involved in using raw external pointers, especially
as the OCaml heap grows and eventually occupies the same region these
pointers once did. But that can't happen until these pointers are
invalidated and reclaimed anyway.

In looking at BigArray as a possible alternative to my FastArrays, I see
that the address passed for such arguments is much like a Custom block and
reaching the arena requires a special offsetting access from the passed
argument address. Hence these cannot be used interchangeably with normal
arrays of double.

I like the idea of moving back away from taking advantage of special
internal knowledge, since that ensures a greater lifetime to my code.
However, it still appears problematic to do so at this time...

In retrospect, it appears that the bus errors may have been caused by a
failed call to my Berkeley DBMS wrappers while the filename string was still
alive and perhaps still in use. Not sure just yet. This is one case where I
should have, and did, put CAMLparam wrappers on that filename string
argument and the Bus Errors subsequently went away.

But wholesale wrapping of all arguments to C glue routines is really not
warranted, and requires careful consideration of when these parameters will
be accessed in the code, and when OCaml heap allocations will occur. Only
those pointers that are both valid, and still live at the time of allocation
need protection by these CAMLparam wrappers.

Do I understand the situation correctly? Or has something more fundamental
changed in 3.08?

David McClain
Senior Corporate Scientist
Avisere, Inc.

+1.520.390.7738 (USA)
david.mcclain@avisere.com



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners