You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7815 Reporter: joris Assigned to:@damiendoligez Status: resolved (set by @xavierleroy on 2018-07-19T15:56:08Z) Resolution: fixed Priority: normal Severity: crash Platform: amd64 OS: linux Version: 4.06.1 Target version: 4.07.1+dev/rc1 Fixed in version: 4.07.1+dev/rc1 Category: runtime system and C interface Monitored by:@nojb@gasche@ygrek@jmeber
Bug description
Calling Gc.full_major (or simply major) after allocating thousands of block of different word size and freeing half of them with first_fit policy makes the runtime crash with no meaningful trace
Steps to reproduce
Compile the attached file with
opam install gperftools # install tcmalloc
Background:
This code is an un-natural example and it was obviously hand-crafted.
I came across this issue after trying to reproduce a bug in minor gc and caml_fl_allocate which under certain conditions makes minor gc run forever (or at least quadratically, but for half an hour on small heaps at least).
I was trying to fill the flp to see what would happen in this case. I don't know yet if those two issues are related
This bug is reproducible by running the bytecode interpreter under valgrind, which should make debugging easier. It seems to be independent of the choice of malloc, although it doesn't seem to actually segfault with the default glibc allocator.
In freelist.c, there's this loop:
value buf [FLP_MAX];
int j = 0;
mlsize_t oldsz = sz;
prev = flp[i];
while (prev != flp[i+1]){
cur = Next (prev);
sz = Wosize_bp (cur);
if (sz > prevsz){
buf[j++] = prev;
prevsz = sz;
if (sz >= oldsz){
CAMLassert (sz == oldsz);
break;
}
}
prev = cur;
}
This example causes 'buf[j++] = prev' (line 345) to run more than FLP_MAX times, overflowing the buffer.
Original bug ID: 7815
Reporter: joris
Assigned to: @damiendoligez
Status: resolved (set by @xavierleroy on 2018-07-19T15:56:08Z)
Resolution: fixed
Priority: normal
Severity: crash
Platform: amd64
OS: linux
Version: 4.06.1
Target version: 4.07.1+dev/rc1
Fixed in version: 4.07.1+dev/rc1
Category: runtime system and C interface
Monitored by: @nojb @gasche @ygrek @jmeber
Bug description
Calling Gc.full_major (or simply major) after allocating thousands of block of different word size and freeing half of them with first_fit policy makes the runtime crash with no meaningful trace
Steps to reproduce
Compile the attached file with
opam install gperftools # install tcmalloc
ocamlfind ocamlopt -g -linkpkg -package gperftools minimal.ml
and run it. On my machine it also crashes with jemalloc with rounds = 3 and nr_blocks = 20000
opam install jemalloc
ocamlfind ocamlopt -g -linkpkg -package jemalloc_ctl minimal.ml
Additional information
Background:
This code is an un-natural example and it was obviously hand-crafted.
I came across this issue after trying to reproduce a bug in minor gc and caml_fl_allocate which under certain conditions makes minor gc run forever (or at least quadratically, but for half an hour on small heaps at least).
I was trying to fill the flp to see what would happen in this case. I don't know yet if those two issues are related
File attachments
The text was updated successfully, but these errors were encountered: