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

double free corruption with bytecode system threads and stack reallocation #5188

Closed
vicuna opened this issue Dec 4, 2010 · 1 comment
Closed
Assignees
Labels

Comments

@vicuna
Copy link

vicuna commented Dec 4, 2010

Original bug ID: 5188
Reporter: herbelin
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2012-03-24T14:01:40Z)
Resolution: fixed
Priority: normal
Severity: crash
Version: 3.11.2
Fixed in version: 3.12.1+dev
Category: ~DO NOT USE (was: OCaml general)
Related to: #7220
Monitored by: @glondu

Bug description

Hi, the following code randomly but most often leads to a double free corruption.

let rec f x = if x = 0 then 0 else 1 + f (x-1)
let _ = Thread.join (Thread.create f 200)

(compiled with "ocamlc -thread unix.cma threads.cma bug.ml").

A valgrind analysis showed that the second illegal free is raised by the instruction "stat_free(th->stack_low);" at line 449 of posix.c: a reallocation of the stack happened but the th and th->stack_low did not get a chance to be updated yet (no entering in a blocking section). The attached patch seems to solve the problem in 3.11.

Apparently, thread implementation has been revised in 3.12 but the problem remains.

Incidentally, with a large system such as Coq, if we link it with the thread library, even though we might not make any use of the functions of the library, we randomly experiment out of memory errors at startup (in native code). Any ideas how to debug this?

Best regards. Hugo.

File attachments

@vicuna
Copy link
Author

vicuna commented Dec 22, 2010

Comment author: @xavierleroy

Well spotted, thanks a lot. I adapted your fix to 3.12 and "committed" it in the 3.12 bugfix branch, for release in 3.12.1. I don't feel this bug warrants a new release of 3.11 but will let our esteemed release manager decide.

As to the random out-of-memory errors at startup, I have no clue, but if you have a (semi-) repro case to suggest, I'll look into it.

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

2 participants