From: John Gerard Malecki <johnm@artisan.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Segfault in a native code multi-threaded program
Date: Sat, 18 Aug 2001 17:24:01 -0700 [thread overview]
Message-ID: <15231.1825.780636.717441@ish.artisan.com> (raw)
In-Reply-To: <3B7EF720.505239B6@maxtal.com.au>
John Max Skaller wrote (2001-08-19T09:15:44+1000):
>
> > <hint for next ocaml ;)>
> >
> > It would be very nice to be able to rely on Marshal as safely as on
> > ocaml typing. Just to be sure that if I expect an int * string, I will
> > effectively receive an int * string or raise an exception. It could
> > probably be done using the same tricks as used in printf formatters.
> >
> > </hint for next ocaml ;)>
>
> As I understand it, this is a non-trivial research problem.
Yes it is but in the mean-time we are stuck with the problem. I'll
describe the IMPERFECT solution i use. If anyone else has something
better please do describe it.
The idea is to use the already existing extract_crc program to get the
digest of the data-structure to be written. There are obvious flaws
including the fact that the value to be written must have a concrete
signature and the programmer must ensure that all of the accessible
signatures are included. Assuming that one didn't make any mistakes
this should catch reading an "out of version" marshaled value.
Here is the text from an email i wrote a while ago describing the same
mechanism followed by all of the code to make a working example.
Under some assumptions about the things that you are writing out
extract_crc can provide some support. The flaw is that extract_crc is
not "deep". If you create a single .mli file which only contains the
signature of the value you are to write then you can, with some
additional makefile complexity, automatically generate an extract_crc
.ml from that .mli file. For example, here is the output from
extract_crc of the cell.mli file
let crc_unit_list = [
"Cell",
"\032\036\180\144\173\052\208\140\081\102\211\172\198\229\098\218"
]
Instead of simply doing an output value you could ALWAYS do an output
value of crc_unit_list and then execute
let safe_output_value safe oc data =
output_value oc safe;
output_value oc data
let safe_input_value safe ic =
let safe_input = input_value ic in
if safe_input = safe then
input_value ic
else
raise (Sys_error "safe_input_value")
The majority of the work is in (makefile) procedures for automatically
generating the crc_unit_list. One must be careful about the
dependencies to make sure that the makefile can both bootstrap and
always keep the crc_unit_list file up to date.
At one time i thought of using the dynlink module to solve these
problems but it turns out that there is no real advantage as the
majority of the work is in the makefile.
Here is a sample Makefile
RESULT := a.out
SOURCES := safety.ml test.ml
all: safety.ml byte-code
include OcamlMakefile
EXTRACT_CRC := $(shell $(OCAMLC) -where)/extract_crc
safety.ml: test.cmi
$(EXTRACT_CRC) test > $@
check: all
OCAMLRUNPARAM='b=1' ./$(RESULT)
The file test.mli
type t = (int * int) list
and the file test.ml
type t = (int * int) list
let safe_output_value safe oc data =
output_value oc safe;
output_value oc data
let safe_input_value safe ic =
let safe_input = input_value ic in
if safe_input = safe then
input_value ic
else
raise (Sys_error "safe_input_value")
let _ =
let data = [ 0,0; 1,1 ] in
let oc = open_out_bin "test.db" in
safe_output_value Safety.crc_unit_list oc data;
close_out oc
let _ =
let ic = open_in_bin "test.db" in
let data = safe_input_value Safety.crc_unit_list ic in
close_in ic;
data
-cheers
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
next prev parent reply other threads:[~2001-08-19 0:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-16 8:08 David Mentre
2001-08-16 12:45 ` Vitaly Lugovsky
2001-08-17 8:09 ` David Mentre
2001-08-17 16:54 ` Brian Rogoff
2001-08-20 9:12 ` David Mentre
2001-08-20 16:54 ` Jun P. FURUSE
2001-08-18 23:15 ` John Max Skaller
2001-08-19 0:24 ` John Gerard Malecki [this message]
2001-08-19 18:18 ` [Caml-list] Ocaml ffi release 1.2.2 dsfox
[not found] ` <3B7C5A74.15141D95@maxtal.com.au>
[not found] ` <qtlitfm6ajh.fsf@pochi.inria.fr>
[not found] ` <3B7F0C99.FEDEAA86@maxtal.com.au>
[not found] ` <qtl3d6m4vkt.fsf@pochi.inria.fr>
2001-08-21 19:20 ` [Caml-list] Segfault in a native code program using pm variants John Max Skaller
2001-08-23 8:54 ` Xavier Leroy
2001-08-20 12:57 [Caml-list] Segfault in a native code multi-threaded program Krishnaswami, Neel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15231.1825.780636.717441@ish.artisan.com \
--to=johnm@artisan.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox