From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id D93197EE35 for ; Thu, 24 Mar 2016 11:26:01 +0100 (CET) IronPort-PHdr: 9a23:mOH8jhbgeEW5Atl5izZIslH/LSx+4OfEezUN459isYplN5qZpci4bnLW6fgltlLVR4KTs6sC0LqG9fmwEjRRqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7D0os2YO1QArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIYTGZn9Kq8xSLgdCDU9L0g04tfqvF/NV1ih/HwZB0oRiQVJBUDb6xeydI38vibgsu1ikH2VOtbpTLZxR3Gox7hmQlnkhXFUZHYC7GjLh5ko3+pgqxW7qkknzg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=goswin-v-b@web.de; spf=Pass smtp.mailfrom=goswin-v-b@web.de; spf=None smtp.helo=postmaster@mout.web.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.17.11; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.17.11 as permitted sender) identity=mailfrom; client-ip=212.227.17.11; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.17.11; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAACcv/NWkwsR49RehAZ9AbJhh24BDYFwIYRcgRACgTQ4FAEBAQEBAQEBEAEBAQEHDQkJIS9BDgGBXYIUAQEBAwEyAUEKCwsYCR4HDwUoCiqIEQEDCggECrs4HysihGUBAQEHAQEBAQEBARmKYoJbgi2CX4IrBZdehXGICYI9hnYKhViPCR4BAYJWgVJrAYdPggQBAQE X-IPAS-Result: A0DJAACcv/NWkwsR49RehAZ9AbJhh24BDYFwIYRcgRACgTQ4FAEBAQEBAQEBEAEBAQEHDQkJIS9BDgGBXYIUAQEBAwEyAUEKCwsYCR4HDwUoCiqIEQEDCggECrs4HysihGUBAQEHAQEBAQEBARmKYoJbgi2CX4IrBZdehXGICYI9hnYKhViPCR4BAYJWgVJrAYdPggQBAQE X-IronPort-AV: E=Sophos;i="5.24,384,1454972400"; d="scan'208";a="170576572" Received: from mout.web.de ([212.227.17.11]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2016 11:26:00 +0100 Received: from frosties.localnet ([134.3.242.84]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LgpVS-1Zx6ys0xmg-00oDxf for ; Thu, 24 Mar 2016 11:26:00 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1aj2Sl-0000K1-IU for caml-list@inria.fr; Thu, 24 Mar 2016 11:25:59 +0100 Date: Thu, 24 Mar 2016 11:25:59 +0100 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20160324102559.GB32689@frosties> References: <20160323105016.GA2235@frosties> <56F2CFD4.4000401@cea.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56F2CFD4.4000401@cea.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:9BmDfXQzziaCRislhNSHADP72L2sX7G7RO1flkibqcnwlDHPmYj tNE57jZ4nKIDdgAOZ9h4ArvjxdStBelV7XQIvzbuFl1sVlH0AeAwpUPBrXYNxnmc6s4HcKf bJDRDohkDH2bI9FXlJA+7VbtG8DpA5hI2ZvWvo46/EZJMr07TNcxXXxFXx16c2UcmxvLVxO wDpkf+NmBJcGmcX6amZpw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+4OkRK6lLoU=:krRpfuwTEz/4PoiAArRcFv whUZFEWiezb5ckgmQG/j0ESWvlFdGy96FJtA4PZf0kGisjdqV8jw3zBKtwNkoIosEt5mPIOVv gHc2pteRHCeOIxEQme+K2RlwmuGXsjbc20WIEgjA0CpffcHvlgsAOUzYC36XqUQqOQB9gR+9o 3epjeyM0RRNx8HHirihP1dgQrtFeRMgsQlFlCqwmI14Xf8Yz2XxJg54jhYPl5TNn+CZOatF7U ebrXqNutzYB0X+Zt7Z8sAyzEy2b8wQMsqfcLwwq1NmgydYmg/xzUWXiyNsZRw3YrN9Y3CixM/ DhS37fAfRmnekhsGYsxYgn3mxEO5LE/yCVbh+TDhlehaVzuTKbz2Xnp7wFrvkgEM5L3cUHbnJ YbPxQzrQAcfYLsX+eoooPiFkUjo8hAQ0o2irdXTTCeQ5+YNMjkjx+a80qaHTY6x22zOkPsHCT XEwbcQicDgTrwjzu4+q14ZetQgOG6eosnjBpB2LUCIkvvlZXAZBPgNrvQNPFg6aAs8NQ4j58g 5WNrvDk5pl15q34SYjV4Rm5wghXn2wPLC+zSj7XaXVLoy3eSzRkoitQIkMLsaLsFPzrixn0a1 UOmnpzMg1GVbBjmOiaQNmDzhubXoopeYRpiWm16+/An1Cs42oAovnht/FT1taggYOUhdmGRHk RQE4xKtZMhcnExgtHbrmN/H1qyAy5iMgfe41oiBsAwJx+OdZa/kA5jlyCDkzDlvp0so7zYYt9 cG3qEhx8MHcyLzamXiz63WgsTEtf9mDAd1auJEgZul+vdE2Q5YggqdCxRHQ= Subject: Re: [Caml-list] RFH: can't figure out why my QT5 widget bindings segfault 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 >> 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.