caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] RFH: can't figure out why my QT5 widget bindings segfault
Date: Fri, 25 Mar 2016 12:28:39 +0100	[thread overview]
Message-ID: <20160325112839.GA27075@frosties> (raw)
In-Reply-To: <20160324102559.GB32689@frosties>

On Thu, Mar 24, 2016 at 11:25:59AM +0100, Goswin von Brederlow wrote:
> 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.

Turns out the problem has nothing directly to do with the ocaml
bindings. The problem is that Qt only allows one active painter per
paint device at a time and has explicit begin()/end() functions to
start and top painting where begin() does error checking. The QPainter
constructor also allows passing the paint device directly, which
automatically calls begin(device) but reports no errors. The
destructor then also automatically calls end().

Problem in ocaml now is that the destructor no longer runs when the
painter goes out of scope but only when the Gc gets around to it. And
for some reason creating a second painter for a device kind of works
(in disregard of what the API says) as long as you don't destroy the
first one half way through, which the Gc does.

I've converted to explicit painter#begin_ and painter#end_ calls and
added some checks in the bindings to enforce them and now everything
works. Now off to adding KeyEvent parsing and one can actually play.

MfG
	Goswin

  reply	other threads:[~2016-03-25 11:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 10:50 Goswin von Brederlow
2016-03-23 15:18 ` Anatoly Zaretsky
2016-03-23 17:18   ` François Bobot
2016-03-24 10:25     ` Goswin von Brederlow
2016-03-25 11:28       ` Goswin von Brederlow [this message]
2016-03-29 22:29         ` SP
2016-03-31 10:21           ` Goswin von Brederlow
2016-03-31 11:00             ` Jonas Jensen
2016-04-02 11:38               ` Goswin von Brederlow
2016-04-06 22:56                 ` SP
2016-04-07  7:43                   ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160325112839.GA27075@frosties \
    --to=goswin-v-b@web.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).