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 F1B287EEF8 for ; Fri, 17 Jul 2015 21:35:14 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of wangshuai901@gmail.com) identity=pra; client-ip=209.85.216.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="wangshuai901@gmail.com"; x-sender="wangshuai901@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of wangshuai901@gmail.com designates 209.85.216.48 as permitted sender) identity=mailfrom; client-ip=209.85.216.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="wangshuai901@gmail.com"; x-sender="wangshuai901@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-vn0-f48.google.com) identity=helo; client-ip=209.85.216.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="wangshuai901@gmail.com"; x-sender="postmaster@mail-vn0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DXAQB6WKlVmzDYVdFagkaBIVoPBoMduBaCJIV7AoFCB0wBAQEBAQESAQEBAQEGCwsJIS6EIwEBAQMBEhEdARsXBgEDAQsGAwILDSoCAiEBAREBBQEcBhMih3YBAwoIDZ0Ijz+BLD4xiz+BbIJ5iyIKGScNV4RXAQEBAQEFAQEBAQEBFgEFDos+gk2BZwEBUAeCaIFDBZFYgm8FhG+CYIJpgWeBQ0aPU4NGghcSI4EVEQaCHByBbyIxAQGBC4E+AQEB X-IPAS-Result: A0DXAQB6WKlVmzDYVdFagkaBIVoPBoMduBaCJIV7AoFCB0wBAQEBAQESAQEBAQEGCwsJIS6EIwEBAQMBEhEdARsXBgEDAQsGAwILDSoCAiEBAREBBQEcBhMih3YBAwoIDZ0Ijz+BLD4xiz+BbIJ5iyIKGScNV4RXAQEBAQEFAQEBAQEBFgEFDos+gk2BZwEBUAeCaIFDBZFYgm8FhG+CYIJpgWeBQ0aPU4NGghcSI4EVEQaCHByBbyIxAQGBC4E+AQEB X-IronPort-AV: E=Sophos;i="5.15,497,1432591200"; d="scan'208";a="140401569" Received: from mail-vn0-f48.google.com ([209.85.216.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jul 2015 21:35:03 +0200 Received: by vnds125 with SMTP id s125so4529132vnd.1 for ; Fri, 17 Jul 2015 12:35:02 -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=/sFZBXEDFFyOLMxYf6cNPIWao40lngxFX3IO5Baowl0=; b=sZUs7D1s33pZnBvM9IjN3Ris1zMFfIBSYGtDfFwCQc6McTxCapYEL4GaVuKF3n9GFW e5qqm/FUm+nkWdj6GvLk74R3aeKvSBagapKW01mBd+aONqaRoUTTePyP0HAiU8xAwXQ9 znrcwW0bafsshI8oFsxbCvRXoeFATVf1oEic8C9sBkhLlXVQpDR6YbqUcbgDl22LYZor i3XpkrmwngNIdfu1yDdH3XX9wTqOq8IRgVk9dVWAC9GtpF5gmTDCUa5NR66mx3vNBic7 8M/PNLdtP/eY8D7eW7gFbTSecAecyMH8LS4ZE+qvbuC6yWYS14Eef8PnHpXQK8QtcQgc 0nEg== MIME-Version: 1.0 X-Received: by 10.52.142.228 with SMTP id rz4mr18619800vdb.61.1437161702160; Fri, 17 Jul 2015 12:35:02 -0700 (PDT) Received: by 10.31.4.8 with HTTP; Fri, 17 Jul 2015 12:35:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2015 15:35:02 -0400 Message-ID: From: Shuai Wang To: Kenneth Adam Miller Cc: caml-list Content-Type: multipart/alternative; boundary=90e6ba475dcfbe0063051b17486c Subject: Re: [Caml-list] Cannot execute "main" function --90e6ba475dcfbe0063051b17486c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, my bad. I figured out the problem due to my carelessness... really sorry for troubling you guys. I hope I didn't waste too much of your time =3D ( On Fri, Jul 17, 2015 at 3:16 PM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > 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 minu= tes >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >> > --90e6ba475dcfbe0063051b17486c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, my bad. I figured out the problem due to my carelessne= ss...=C2=A0
really sorry for troubling you guys. I hope I didn't wa= ste too much of your time =3D (

<= div class=3D"gmail_quote">On Fri, Jul 17, 2015 at 3:16 PM, Kenneth Adam Mil= ler <kennethadammiller@gmail.com> wrote:
If you are certain that you can d= o a make clean, git checkout of the previous revision to where this wasn= 9;t occurring, rebuild and confirm that this still happens, then it certain= ly seems like this is a environment issue.

On F= ri, Jul 17, 2015 at 3:13 PM, Shuai Wang <wangshuai901@gmail.com&g= t; wrote:
= =E2=98=81 =C2=A0src [master] =E2=9A=A1 ldd init.native
linux-vdso.so.1 =3D> =C2=A0(0x00007ff= f55dfe000)
libpthrea= d.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa4fc9c0000)
libm.so.6 =3D> /li= b/x86_64-linux-gnu/libm.so.6 (0x00007fa4fc6c4000)
libdl.so.2 =3D> /lib/x86_64-linux-gnu/libd= l.so.2 (0x00007fa4fc4bf000)
= libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa4fc1010= 00)
/lib64/ld-linux-= x86-64.so.2 (0x00007fa4fcbfe000)

On Fri, Jul 17, 2015 at 3:11 PM, Ivan = Gotovchits <ivg@ieee.org> wrote:
Can you show the output 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 Ivan,

Thank you for yo= ur reply! aha, it is not related to BAP ;)=C2=A0

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

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

Sincerely,
Shuai





=

On Fri, Jul 17, 2015 at 2:51 PM, Ivan Gotovchits <ivg@ieee.org&g= t; wrote:
In OCam= l all module level expressions are evaluated in order of their appearance. = If you have some function
that you designate as a "main" func= tion*, then before this function is entered all modules on which module,=C2= =A0
containing "main" function, depends. So you need to= find, whether you added some code, that evaluates before=C2=A0
y= our main.

* there is no such function as main func= tion in OCaml. All modules are evaluated in the order of their occurrence
on the compilation string. Usually, the order is defined by a buil= d tool, like `ocamlbuild`, that will put the entry module=C2=A0
i= n the last place, and topologically sort the preceding modules.
<= br>
P.S. I hope that this is not related to BAP? ;)=C2=A0

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

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

This morning I changed some code, comp= iled it and let it processing some large 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 minutes before entering into "main&q= uot; function!

<= div style=3D"font-size:12.8000001907349px">I tried to clean the whole codeb= ase, and recompile it ( I use ocamlbuild 4.01.0), but the same wired situat= ion still happens..=C2=A0
=
I did this:

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

and I got this output flushing out for a very long time (sorry= mail list blocks my large image.. ):



=

Is anyon= e aware this kind of issue before..? Am I messed up something..?=C2=A0
I have been working on OCaml f= or a relatively long time and I didn't encounter this kind of stuff bef= ore...


Sincerely,
S= huai






--90e6ba475dcfbe0063051b17486c--