Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEGV when using Gc.finalise #2893

Closed
vicuna opened this issue Jul 3, 2004 · 3 comments
Closed

SEGV when using Gc.finalise #2893

vicuna opened this issue Jul 3, 2004 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 3, 2004

Original bug ID: 2893
Reporter: administrator
Status: closed (set by @damiendoligez on 2007-12-06T14:34:06Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 3.08.0
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Mike Furr
Version: 3.07 & cvs-3.08
OS: OS X & linux
Submission from: pcp01781388pcs.howard01.md.comcast.net (68.32.48.24)

The program below segfaults on my mac and my linux box when compiled with
either the native code or byte code compilers. I have observed this behavior in

both 3.07 and the branch tagged release308 in CVS(7/2/04). This particular
version of the program segv's on 3.08, but not 3.07, but I can supply a larger
version which kills 3.07 if it would help(I tried to create the smallest test
case
to trigger it).
I'm running Debian/unstable on my i386 linux box and OS X 10.2 on my mac.
Note, while trying to slim down the program to submit, I got different
backtraces from gdb along the way...so it seems that the stack is being smashed
somewhere and thus I don't know how useful a bt would be, but here is one
just in case:
furrm@Kamino:~/devel/cache$ gdb ./test
[...]
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .. done
(gdb) run
Starting program: /Users/furrm/devel/cache/test
[Switching to process 19826 thread 0xb03]
Reading symbols for shared libraries .. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00022608 in caml_fl_allocate ()
(gdb) bt
#0 0x00022608 in caml_fl_allocate ()
#1 0x00015f70 in caml_alloc_shr ()
#2 0x0001f150 in caml_weak_create ()
#3 0x00013234 in caml_c_call ()
Cannot access memory at address 0x181

Here is the program:

module H =
struct
type t = string
let equal t1 t2 = (String.compare t1 t2 = 0)
let hash = Hashtbl.hash
end

module Cache = Weak.Make (H)

let final elt = ()

let cache = Cache.create 2047;;

let _ =
for i = 0 to 100000 do
let v = String.create ((i mod 10)+1) in
Gc.finalise final v;
Cache.add cache v
done

Let me know if I can provide any other information.

@vicuna
Copy link
Author

vicuna commented Jul 3, 2004

Comment author: administrator

Full_Name: Mike Furr
Version: 3.07 & cvs-3.08

The program below segfaults on my mac and my linux box when compiled with
either the native code or byte code compilers. I have observed this behavior
in
both 3.07 and the branch tagged release308 in CVS(7/2/04). This particular
version of the program segv's on 3.08, but not 3.07, but I can supply a
larger
version which kills 3.07 if it would help(I tried to create the smallest test
case to trigger it).

Thanks for finding this bug. It is now fixed in the release308 branch.
However, I'm still interested in a reproduction case for 3.07, since it seems
to be a different bug.

-- Damien

@vicuna
Copy link
Author

vicuna commented Jul 3, 2004

Comment author: administrator

On Sat, 3 Jul 2004, Damien Doligez wrote:

Thanks for finding this bug. It is now fixed in the release308 branch.
However, I'm still interested in a reproduction case for 3.07, since it seems
to be a different bug.
Attached. This program crashes on my mac with 3.07 and uses all available
memory(1G) on my linux box. It appears to run correctly with 3.08alpha
after your recent changes.

-mike


open Printf

type elt = {
id : int;
mutable life : int;
data : string;
}

let uniq = ref 0;;

module H =
struct
type t = elt
let equal t1 t2 = t1.id = t2.id
let hash t = Hashtbl.hash t.id
end

module Cache = Weak.Make (H)

let keeparound = Hashtbl.create 127;;

let cache = Cache.create 2047;;

let mk num =
incr uniq;
{id = !uniq;
life = 1;
data = String.create ((num mod 10)+1);
}

let alarm () = Hashtbl.clear keeparound

let rec final elt =
if elt.life > 0 then
begin
(* Gc.finalise final elt *)
elt.life <- elt.life - 1;
Hashtbl.add keeparound elt elt.id;
end
else begin
fprintf stderr "freeing %d\n" elt.id;
flush stderr;
end

let _ =
ignore(Gc.create_alarm alarm);
let count = ref 0 in
for i = 0 to 100000 do
let v = mk i in
Gc.finalise final v;
(*Cache.add cache v -- segv's withor without this line *)
done;
Gc.full_major();
Gc.print_stat stdout


@vicuna
Copy link
Author

vicuna commented Jul 12, 2004

Comment author: administrator

fixed for 3.08+alpha --DD 2004-07-03
can't reproduce crash on 3.07+2
uses all memory because of reentrancy into Hashtbl.resize

@vicuna vicuna closed this as completed Dec 6, 2007
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant