Re: [Caml-list] RFH: can't figure out why my QT5 widget bindings segfault

[Goswin von Brederlow <goswin-v-b@web.de>]

On Wed, Mar 23, 2016 at 06:18:12PM +0100, François Bobot wrote:
> On 23/03/2016 16:18, Anatoly Zaretsky wrote:
> >On Wed, Mar 23, 2016 at 12:50 PM, Goswin von Brederlow <goswin-v-b@web.de
> ><mailto:goswin-v-b@web.de>> wrote:
> >
> >    I'm stuck with a bug in the Tetrix example for my QT5 bindings:
> >
> >    https://github.com/mrvn/ocaml-qt5
> >
> >    The segfault happens when you click start and the first piece is moved
> >    one tile down in caml_mrvn_QT5_OPainter_fillRect. The arguments to the
> >    call all look ok but something must corrupt the painter. The segfault
> >    goes away when I force a Gc.full_major before creating a new OPainter
> >    in TetrixBoard:148.
> >
> >
> >Just a wild guess: there are a lot of raw c++ pointer casts to ocaml values in the code, and to
> >quote http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html#sec424 "this can crash the garbage
> >collector" in some non-obvious circumstances.

I know about that and all c++ pointers are paired with an ocaml object
that holds them. The c++ object also holds a weak refrence to the
ocaml object. When the c++ object is destructed it removes the pointer
from the paired ocaml object before being freed. Therefore there can
never be a reachable danling pointer on the ocaml heap that could
potentially point the next ocaml heap. 

It also seems like the heap and c++ allocations are at opposite ends
of the address space, e.g. from the debug output:

  value caml_mrvn_Qt5_OClass_register_obj(OClass*, value)(0x113bbe8, 0x7f4cfac1cfa8)

The c++ object is at 0x113bbe8, the lower end of the heap and the
ocaml object at 0x7f4cfac1cfa8, the upper end of the heap.

> And in the future of no-naked pointer it will be forbidden. Perhaps it
> should be added to the ocaml documentation with the precise future rules
> [1].

That will break a lot of code and will be rather anyoing. I guess for
me it's time to overload operator new() to add a black colored ocaml
header before every allocation.

More generally what I often wish I had would be a block that holds
both ocaml values and at least one C pointer. Could we have a tag(s) for
blocks where the Gc skips the first field(s) and only scans the rest?

> The segfault is in C++ code, so I think it is not this problem. Moreover no
> asserts of the debug runtime are broken. On debian I don't know how to
> install qt5 in debug mode, so I'm not able to see in gdb which pointer is at
> fault.
> 
> NB: the INSTALL file forget to ask to install qt5 development file, even if it is obviously needed ;).
> 
> [1]: https://github.com/ocaml/ocaml/pull/297#issuecomment-159233967

Yeah, it's still at the proof-of-concept stage. The INSTALL is oasis
generated and I haven't even looked at what oasis puts in there. No
opam package yet either.