caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Adrien <camaradetux@gmail.com>
To: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Timing module initializations (working but crashy)
Date: Tue, 10 Apr 2012 18:25:05 +0200	[thread overview]
Message-ID: <CAP5QFJnmMiMt8XqVDXPE8xRzyJYZuyjWeY=QRdHquacngkFoOQ@mail.gmail.com> (raw)
In-Reply-To: <CAP5QFJnwf88ov00cjoXNBYDPj9P6r6nXHJdn_5Yp+i6stX6o-Q@mail.gmail.com>

Hi,

Kaustuv Chaudhuri mentionned a few things about this issue on IRC.

First, one thing I had forgotten in my previous email: I've tried making
the functions usual ocaml-callable C functions (with
CAML{param,local,return}*) but that didn't change anything. The
segfaults still occurs in the exact same place.

I've also removed the intermediate function. It generates ten times more
C code but removing the indirection should reduce the number of possible
issues. However the issue still happens at the same place.

Finally, by printing the addresses of the entry functions, we got the
following output:
  [...]
  (* this is GtkMain disabling auto-compaction *)
  New max overhead: 1000000%
  [...]

  Initialiazing OgtkFileProps through 0x50d170.
  Done initialiazing OgtkFileProps through 0x50d3bc.
  23.016000 microseconds spent initializing OgtkFileProps.

  Initialiazing GContainer through 0x50e8b0.
  Done initialiazing GContainer through 0x1.
  483.846000 microseconds spent initializing GContainer.

  Initialiazing GPack through 0x511fa0.
  Done initialiazing GPack through 0x1.
  1931.545000 microseconds spent initializing GPack.

  Initialiazing GButton through 0x5165c0.
  <
  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000581176 in caml_oldify_local_roots ()

I don't really understand why (and, to be honest, how) the function
pointer would change but maybe there's something I don't fully know with
function pointers and printf's %p format.

I've put a new file online with the aforementionned changes:
  http://notk.org/~adrien/link2.ml

Any input is particularly appreciated. :-)

By the way, a few reasons I've started this: startup speed, potential
very slow initializations for which there was no instrumentation,
detecting useless code that impacts runtime, and the fact that I want to
make an application "not get start slower" but I had no hard numbers on
how how fast it currently starts.

-- 
Adrien Nader

      reply	other threads:[~2012-04-10 16:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-08 22:30 Adrien
2012-04-10 16:25 ` Adrien [this message]

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='CAP5QFJnmMiMt8XqVDXPE8xRzyJYZuyjWeY=QRdHquacngkFoOQ@mail.gmail.com' \
    --to=camaradetux@gmail.com \
    --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).