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 ED6067EEF8 for ; Fri, 17 Jul 2015 21:37:26 +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.218.47; 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.218.47 as permitted sender) identity=mailfrom; client-ip=209.85.218.47; 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-oi0-f47.google.com) identity=helo; client-ip=209.85.218.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DXAQB6WKlVmy/aVdFagkaBIVoPBoMduBaCJIV7AoFCB0wBAQEBAQESAQEBAQEGCwsJIS6EIwEBAQMBEhEdARsXBgEDAQsGAwILDSoCAiEBAREBBQEcBhMih3YBAwoIDZ0Ijz+BLD4xiz+BbIJ5iyIKGScNV4RXAQEBAQEBBAEBAQEBARYBBQ6LPoJNgWcBAVAHgmiBQwWRWIJ0hG+CYIJpgWeBQ0aPU4NGghcSI4EVEQaCHByBbyIxAQGBC4E+AQEB X-IPAS-Result: A0DXAQB6WKlVmy/aVdFagkaBIVoPBoMduBaCJIV7AoFCB0wBAQEBAQESAQEBAQEGCwsJIS6EIwEBAQMBEhEdARsXBgEDAQsGAwILDSoCAiEBAREBBQEcBhMih3YBAwoIDZ0Ijz+BLD4xiz+BbIJ5iyIKGScNV4RXAQEBAQEBBAEBAQEBARYBBQ6LPoJNgWcBAVAHgmiBQwWRWIJ0hG+CYIJpgWeBQ0aPU4NGghcSI4EVEQaCHByBbyIxAQGBC4E+AQEB X-IronPort-AV: E=Sophos;i="5.15,497,1432591200"; d="scan'208";a="140401691" Received: from mail-oi0-f47.google.com ([209.85.218.47]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jul 2015 21:37:25 +0200 Received: by oigd21 with SMTP id d21so34511575oig.1 for ; Fri, 17 Jul 2015 12:37:24 -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=WXbrVDDdoSWVpn4EFZ0cuFaM1b+T7Hf3b89CNM69TJ4=; b=ujjnxGL/66P81zf/hqVWXxAC08nrQQbLMZUIPHPrpmS+SjbLxZhsA6MC28vRCyc1It KPZMvktQhuLo8aSxT7pvu1TwEJAFsUJ5Q7AinARxg0jjmZWTlHvsQ/2/O7NUfuQmX3xB z+TkEdYHrv772VKS85+q/WbeYCrUFoOHM02idDM04U3VZSuRfC7Z8liy/p26iBdVczps R35kfAch/QQmde6wOfmQAmft8qYQI/7ZDU4Js3IJRi/dCPeS1aJRfOEOpeUk6TsTSeU7 xo4EknnUM3IkAEzLJVJQfAImS+aoXQbijEOdLL1st0U6dRG6HxHrKOA+PIX4lRn6uORo C0Rw== MIME-Version: 1.0 X-Received: by 10.182.20.141 with SMTP id n13mr15766363obe.26.1437161844532; Fri, 17 Jul 2015 12:37:24 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Fri, 17 Jul 2015 12:37:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2015 15:37:24 -0400 Message-ID: From: Kenneth Adam Miller To: Shuai Wang Cc: caml-list Content-Type: multipart/alternative; boundary=e89a8f923bea3a6b69051b175199 Subject: Re: [Caml-list] Cannot execute "main" function --e89a8f923bea3a6b69051b175199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nah, it's no problem at all. :) On Fri, Jul 17, 2015 at 3:35 PM, Shuai Wang wrote: > 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 th= at >> 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 min= utes >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --e89a8f923bea3a6b69051b175199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nah, it's no problem at all. :)

On Fri, Jul 17, 2015 at 3:35 PM, S= huai Wang <wangshuai901@gmail.com> wrote:
OK, my bad. I figured out the problem= due to my carelessness...=C2=A0
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 cl= ean, git checkout of the previous revision to where this wasn't occurri= ng, rebuild and confirm that this still happens, then it certainly seems li= ke this is a environment issue.
<= br>
On Fri, Jul 17, 2015 at 3:13 PM, Shuai Wang <= span dir=3D"ltr"><wangshuai901@gmail.com> wrote:
=E2=98=81 =C2=A0src [master] =E2=9A=A1 ldd = init.native
linux-vd= so.so.1 =3D> =C2=A0(0x00007fff55dfe000)
libpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpth= read.so.0 (0x00007fa4fc9c0000)
libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa4fc6= c4000)
libdl.so.2 = =3D> /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa4fc4bf000)
libc.so.6 =3D> /lib/x86_64-lin= ux-gnu/libc.so.6 (0x00007fa4fc101000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa4fcbfe000)

On F= ri, Jul 17, 2015 at 3:11 PM, Ivan Gotovchits <ivg@ieee.org> wrot= e:
Can you show the outp= ut of `ldd` on your main executable, e.g., =C2=A0`ldd init.native`?

On Fri, J= ul 17, 2015 at 3:07 PM, Shuai Wang <wangshuai901@gmail.com> wrote:
Hello Ivan,<= div>
Thank you for your 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 previous version which works fine. But it i= s still trapped in this way..

By looking at the lt= race 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






On Fri, Jul 17, 2015 at 2:5= 1 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







--e89a8f923bea3a6b69051b175199--