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 9C5CF7EEF8 for ; Fri, 17 Jul 2015 21:16:51 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.214.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.214.181 as permitted sender) identity=mailfrom; client-ip=209.85.214.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; 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@mail-ob0-f181.google.com) identity=helo; client-ip=209.85.214.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f181.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwAgD8U6lVlbXWVdFagkZsNVoPBoMduBaCJIV7AoFCB0wBAQEBAQESAQEBAQcNCQkfMIQkAQEEEhEdARsXBgEDDAYDAgsNKgICIQEBEQEFARwGEyKHdgEDEg2dHI8/gSw+MYs/gWyCeYskChknDVeEVwEBAQEBAQQBAQEBAQEBFQEFDos+gk2BZwEBUAeCaIFDBZFYgnSEb4JggmmBZ4FDRo9Tg0aCFxIjgRURBoIcHIFvIjEBAYELgT4BAQE X-IPAS-Result: A0CwAgD8U6lVlbXWVdFagkZsNVoPBoMduBaCJIV7AoFCB0wBAQEBAQESAQEBAQcNCQkfMIQkAQEEEhEdARsXBgEDDAYDAgsNKgICIQEBEQEFARwGEyKHdgEDEg2dHI8/gSw+MYs/gWyCeYskChknDVeEVwEBAQEBAQQBAQEBAQEBFQEFDos+gk2BZwEBUAeCaIFDBZFYgnSEb4JggmmBZ4FDRo9Tg0aCFxIjgRURBoIcHIFvIjEBAYELgT4BAQE X-IronPort-AV: E=Sophos;i="5.15,497,1432591200"; d="scan'208";a="140400666" Received: from mail-ob0-f181.google.com ([209.85.214.181]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jul 2015 21:16:50 +0200 Received: by obre1 with SMTP id e1so71485586obr.1 for ; Fri, 17 Jul 2015 12:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vqSJ3FMZa6F18tXgFwlM4lAQTSxUMOeqYwjxVzLP++Q=; b=kWNppIneUoXLulMXjPIenju5D4b3mR9cCyC3B7h3vsCXMZOmI9NaJJvdwX/Ho/+Cb0 V4TyNlWe/xjpUR9OPeW5MOjvRmH+aYHE38Var9MaP+tPZaQucQPJU+CLlwAPWefD1qGQ rE8QFtO8/h+QDDXiS2p7p4kWzt+vxWI8XxlojH+mLW5llz+ASNNckF9t/VgcSJ8nEDYP jjr+KKocNaH3hnKffUXd1oXrXC5n/HZim2miv6fk+nqrAELtbxgei3Iucn52EpyGVH25 I6cAtU8I27K3fUNyxhyUdkY0ht4E3qpDex2qOpd0MDkRv3lJJPMFb6B1r4DJkUsjsLHF d3fQ== MIME-Version: 1.0 X-Received: by 10.60.177.195 with SMTP id cs3mr14923885oec.37.1437160609140; Fri, 17 Jul 2015 12:16:49 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Fri, 17 Jul 2015 12:16:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2015 15:16:49 -0400 Message-ID: From: Kenneth Adam Miller To: Shuai Wang Cc: caml-list Content-Type: multipart/alternative; boundary=089e010d8f4897d925051b170726 Subject: Re: [Caml-list] Cannot execute "main" function --089e010d8f4897d925051b170726 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you are certain that you can do a make clean, git checkout of the previous revision to where this wasn't occurring, rebuild and confirm that this still happens, then it certainly seems like this is a environment issue. On Fri, Jul 17, 2015 at 3:13 PM, Shuai Wang wrote: > =E2=98=81 src [master] =E2=9A=A1 ldd init.native > linux-vdso.so.1 =3D> (0x00007fff55dfe000) > libpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0 > (0x00007fa4fc9c0000) > libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa4fc6c4000) > libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa4fc4bf000) > libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa4fc101000) > /lib64/ld-linux-x86-64.so.2 (0x00007fa4fcbfe000) > > On Fri, Jul 17, 2015 at 3:11 PM, Ivan Gotovchits wrote: > >> Can you show the output of `ldd` on your main executable, e.g., `ldd >> init.native`? >> >> On Fri, Jul 17, 2015 at 3:07 PM, Shuai Wang >> wrote: >> >>> Hello Ivan, >>> >>> Thank you for your reply! aha, it is not related to BAP ;) >>> >>> I didn't touch the code in init.ml for a long time, and I have tried to >>> roll back >>> to previous version which works fine. But it is still trapped in this >>> way.. >>> >>> By looking at the ltrace output, IMHO, is there any chance that some >>> setting up code of runtime system does not work well? I am probably >>> wrong. >>> >>> Sincerely, >>> Shuai >>> >>> >>> >>> >>> >>> >>> On Fri, Jul 17, 2015 at 2:51 PM, Ivan Gotovchits wrote: >>> >>>> In OCaml all module level expressions are evaluated in order of their >>>> appearance. If you have some function >>>> that you designate as a "main" function*, then before this function is >>>> entered all modules on which module, >>>> containing "main" function, depends. So you need to find, whether you >>>> added some code, that evaluates before >>>> your main. >>>> >>>> * there is no such function as main function in OCaml. All modules are >>>> evaluated in the order of their occurrence >>>> on the compilation string. Usually, the order is defined by a build >>>> tool, like `ocamlbuild`, that will put the entry module >>>> in the last place, and topologically sort the preceding modules. >>>> >>>> P.S. I hope that this is not related to BAP? ;) >>>> >>>> On Fri, Jul 17, 2015 at 2:35 PM, Shuai Wang >>>> wrote: >>>> >>>>> Dear list, >>>>> >>>>> >>>>> I am working on some tools written in OCaml (compiled by OCaml version >>>>> 4.01.0). >>>>> >>>>> This morning I changed some code, compiled it and let it processing >>>>> some large data (~ 4G), it never stops after over 2 hours. >>>>> >>>>> I feed the tool with a tiny input which took less than 1 second to >>>>> process before, and I figured out that now it takes around 2.5 minut= es >>>>> before entering into "main" function! >>>>> >>>>> I tried to clean the whole codebase, and recompile it ( I use >>>>> ocamlbuild 4.01.0), but the same wired situation still happens.. >>>>> >>>>> I did this: >>>>> >>>>> ltrace ./init.native input >>>>> >>>>> and I got this output flushing out for a very long time (sorry mail >>>>> list blocks my large image.. ): >>>>> >>>>> http://i.stack.imgur.com/sEkKk.png >>>>> >>>>> >>>>> >>>>> Is anyone aware this kind of issue before..? Am I messed up >>>>> something..? >>>>> I have been working on OCaml for a relatively long time and I didn't >>>>> encounter this kind of stuff before... >>>>> >>>>> >>>>> Sincerely, >>>>> Shuai >>>>> >>>> >>>> >>> >> > --089e010d8f4897d925051b170726 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are certain that you can do a make clean, git check= out of the previous revision to where this wasn't occurring, rebuild an= d confirm that this still happens, then it certainly seems like this is a e= nvironment issue.

On Fri, Jul 17, 2015 at 3:13 PM, Shuai Wang <wangshuai901@gmail= .com> wrote:
=E2=98=81 =C2=A0src [master] =E2=9A=A1 ldd init.native
linux-vdso.so.1 =3D> =C2=A0(0= x00007fff55dfe000)
l= ibpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa4fc9= c0000)
libm.so.6 =3D= > /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa4fc6c4000)
libdl.so.2 =3D> /lib/x86_64-linux-= gnu/libdl.so.2 (0x00007fa4fc4bf000)
libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007f= a4fc101000)
/lib64/l= d-linux-x86-64.so.2 (0x00007fa4fcbfe000)
<= div class=3D"h5">

= On Fri, Jul 17, 2015 at 3:11 PM, Ivan Gotovchits <ivg@ieee.org> w= rote:
Can you show the o= utput of `ldd` on your main executable, e.g., =C2=A0`ldd init.native`?

On Fri= , Jul 17, 2015 at 3:07 PM, Shuai Wang <wangshuai901@gmail.com>= wrote:
Hello Iva= n,

Thank you for your reply! aha, it is not related to B= AP ;)=C2=A0

I didn't touch the code in init.ml for a long time, and I ha= ve tried to roll back
to previous version which works fine. But i= t is still trapped in this way..

By looking at the= ltrace output, IMHO, is there any chance that some=C2=A0
setting= up code of runtime system does not work well? I am probably wrong.

Sincerely,
Shuai


<= /div>




On Fri, Jul 17, 2015 at 2:= 51 PM, Ivan Gotovchits <ivg@ieee.org> wrote:
In OCaml all module level expressions are ev= aluated in order of their appearance. If you have some function
that yo= u designate as a "main" function*, then before this function is e= ntered all modules on which module,=C2=A0
containing "main&q= uot; function, depends. So you need to find, whether you added some code, t= hat evaluates before=C2=A0
your main.

* = there is no such function as main function in OCaml. All modules are evalua= ted in the order of their occurrence
on the compilation string. U= sually, the order is defined by a build tool, like `ocamlbuild`, that will = put the entry module=C2=A0
in the last place, and topologically s= ort the preceding modules.

P.S. I hope that this i= s not related to BAP? ;)=C2=A0

On Fri, Jul 17, 2015 at 2:35 PM, Shuai Wang = <wangshuai901@gmail.com> wrote:
Dear list,


I am working on some tools written in OCa= ml (compiled by OCaml version 4.01.0).=C2=A0

Th= is morning I changed some code, compiled it and let it processing some larg= e data (~ 4G), it never stops after over 2 hours.=C2=A0

I feed the tool with a tiny input which took less than 1 second to= process before, and =C2=A0I figured out that now it takes around 2.5 minut= es before entering into "main" function!

I tried to clean the whole codebase, and recompile it ( I use ocamlbuil= d 4.01.0), but the same wired situation still happens..=C2=A0

I did this:

=C2=A0 =C2=A0 ltrace= ./init.native input

<= /div>
and I got this output flus= hing out for a very long time (sorry mail list blocks my large image.. ):

http://i.stack.imgur.com/sEkKk.png



Is anyone aware this kind of issue before..? A= m I messed up something..?=C2=A0
I have been working on OCaml for a relatively long time and I didn&#= 39;t encounter this kind of stuff before...

Sincerely,
Shuai





--089e010d8f4897d925051b170726--