Re: "ocaml_beginners"::[] Byte-code fine; native-code segfaults

Hi,

And thanks for the prompt reply!

> Well, if it is native code, you could let the system write
&gt; coredumps (ulimit -c <max_blocks> ) and use gdb to look at them.
&gt;
> You also should be able to run the program inside gdb
> (invoked by gdb).
&gt;
> But I'm not sure how far gdb really can be used here.

I should have mentioned that I had already tried the more
obvious solutions of gdb and strace. The former cannot be
used, because ocamlopt does not produce debug symbols
(there's no -g option in 3.09), and honestly, I couldn't
really figure out what the latter produces:

read(3, ":18:58.125819&#43;010033360034250&quot;..., 4096) = 4096
munmap(0xb7e14000, 253952) = 0
read(3, "467352007-07-30 21:18:58.12581"..., 4096) = 3313
--- SIGSEGV (Segmentation fault) 0 (0) ---
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
rt_sigaction(SIGSEGV, , NULL, 8) = 0
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) 0 (0) ---
+;++ killed by SIGSEGV (core dumped) +++

The only weird thing I notice there is the mismatch 4096 != 3313
in the last read before the crash.

> At least gprof for time-profiling can be used together with OCaml
&gt; native code. Maybe there is also some kind of support for gdb?

Not that I know of.

&gt; indefinitley sounds very unfine.
> I think you meant infinitly?!

No, I meant "indefinitely&quot;. It also carries the meaning
of "endlessly".

> Did you used any self-written external C-stuff?
> This could cause problems, if you have written unstable C-code.

Nope. The programme is quite small. And as far as I can tell,
the PG'OCaml library is pure OCaml code.

> Sorry, I don't want to offend the OCaml-core team ( the Guru's )
> but as far as I have read in the mails on this list,
&gt; OCaml 3.10.0 also has some instability problems?!

Really? I haven't heard of those yet. If true, I hope they get
sorted out soon, because the natdynlink is a killer feature for me!

Cheers,
C.S.

Zitat von cultural_sublimation < cultural_sublimation%40yahoo.com">cultural_sublimationyahoo.com>:

> Hi,
>
> And thanks for the prompt reply!
&gt;
> > Well, if it is native code, you could let the system write
&gt; > coredumps (ulimit -c <max_blocks> ) and use gdb to look at them.
&gt; >
>; > You also should be able to run the program inside gdb
> > (invoked by gdb).
&gt; >
>; > But I'm not sure how far gdb really can be used here.
&gt;
> I should have mentioned that I had already tried the more
>; obvious solutions of gdb and strace. The former cannot be
> used, because ocamlopt does not produce debug symbols
> (there's no -g option in 3.09), and honestly, I couldn't
> really figure out what the latter produces:
>
&gt; read(3, ":18:58.125819&#43;010033360034250&quot;..., 4096) = 4096
>; munmap(0xb7e14000, 253952) = 0
> read(3, "467352007-07-30 21:18:58.12581"..., 4096) = 3313
>; --- SIGSEGV (Segmentation fault) 0 (0) ---
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> rt_sigaction(SIGSEGV, , NULL, 8) = 0
> sigreturn() = ? (mask now [])
> --- SIGSEGV (Segmentation fault) 0 (0) ---
> +++ killed by SIGSEGV (core dumped) +++
>
> The only weird thing I notice there is the mismatch 4096 != 3313
>; in the last read before the crash.

It's a read from an opened filedescriptor,
possibly a file or a pipe or a socket.
The mismatch means: the buffer of the read has 4096 Bytes,
but only 3313 bytes were read.
This looks like a pipe/socket, because with files this normally does not happen.

But this should not be a problem, if the application checks
the return value of the read.

It can only use that much bytes (3313) from the buffer.

If it uses the buffer directly to print something,
possibly waiting for the string-end delimiter (a )
but did not get it, this could cause the crash.

For example, if the buffer is not completely filled with ,
and you use it for a printf(&quot;%s", buffer);
the printf awaits a delimited string.
But possibly it does not get it, and printf
reads up too much bytes.
But I could not imagine some lines of code that would make such a problem here,
but would otherwise work correctly.
At least the last byte of the buffer should have a at the end.

So, possibly the read (or the reading process) awaits also to get a
in the stuff it reads, and use it as a string delimiter, but because the
(possibly) pipe (or socket) will only read up to 3313 Bytes, the is not read
and the
printf crashes the whole process.

These are only things I *could imagine* and maybe that is not the case.
There would be many other possibilities, but this *could* be one possible
problem.

I'm not quite clear, where the munmap comes from, but it possibly is from
a library, that calls it. (As you said that there is no C-code in your
application, I doubt it comes from your application itself.)
It would be necessary to see more of the strace-output to see,
what is happening there.

But the mmap/read/munmap could be part of the library calls.
mmap/munmap makes IO faster.

[...]
> > indefinitley sounds very unfine.
> > I think you meant infinitly?!
>
> No, I meant "indefinitely&quot;. It also carries the meaning
> of "endlessly".
>

ah, ok, sorry, my bad english

Ciao,
Oliver

P.S.: Possibly an interrupted systemcall that is not correctly handled,
which than yields to problems here...
If it would be possible to provide code, people could look at it
in more detail, possibly checking if the behaviour is the same on
their machines.

•  9
  New Members

• Computer telephony
• Portable computer
• Computer telephony integration
• Computer telephony integration cti
• Portable computer cart

On Friday 17 August 2007 00:48:01 cultural_sublimation wrote:
&gt; getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0

Are you sure it isn't a stack overflow?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

On Thu, Aug 16, 2007 at 11:48:01PM -0000, cultural_sublimation wrote:
&gt; read(3, ":18:58.125819&#43;010033360034250&quot;..., 4096) = 4096
>; munmap(0xb7e14000, 253952) = 0
> read(3, "467352007-07-30 21:18:58.12581"..., 4096) = 3313
>; --- SIGSEGV (Segmentation fault) 0 (0) ---
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> rt_sigaction(SIGSEGV, , NULL, 8) = 0
> sigreturn() = ? (mask now [])
> --- SIGSEGV (Segmentation fault) 0 (0) ---
> +++ killed by SIGSEGV (core dumped) +++

This indicates that you've got a stack overflow in your code.
Probably one of your recursive functions isn't tail recursive.

Rich.

--
Richard Jones
Red Hat

Zitat von Oliver Bandel < oliver%40first.in-berlin.de">oliverfirst.in-berlin.de>:

> Zitat von cultural_sublimation < cultural_sublimation%40yahoo.com">cultural_sublimationyahoo.com>:
>;
> > Hi,
> >
>; > And thanks for the prompt reply!
&gt; >
>; > > Well, if it is native code, you could let the system write
&gt; > > coredumps (ulimit -c <max_blocks> ) and use gdb to look at them.
&gt; > >
>; > > You also should be able to run the program inside gdb
> > > (invoked by gdb).
&gt; > >
>; > > But I'm not sure how far gdb really can be used here.
&gt; >
>; > I should have mentioned that I had already tried the more
>; > obvious solutions of gdb and strace. The former cannot be
> > used, because ocamlopt does not produce debug symbols
> > (there's no -g option in 3.09), and honestly, I couldn't
> > really figure out what the latter produces:
> >
>; > read(3, ":18:58.125819&#43;010033360034250&quot;..., 4096) = 4096
>; > munmap(0xb7e14000, 253952) = 0
> > read(3, "467352007-07-30 21:18:58.12581"..., 4096) = 3313
>; > --- SIGSEGV (Segmentation fault) 0 (0) ---
> > getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> > rt_sigaction(SIGSEGV, , NULL, 8) = 0
> > sigreturn() = ? (mask now [])
> > --- SIGSEGV (Segmentation fault) 0 (0) ---
> > +++ killed by SIGSEGV (core dumped) +++
> >
>; > The only weird thing I notice there is the mismatch 4096 != 3313
>; > in the last read before the crash.
&gt;
> It's a read from an opened filedescriptor,
>; possibly a file or a pipe or a socket.
> The mismatch means: the buffer of the read has 4096 Bytes,
&gt; but only 3313 bytes were read.
&gt; This looks like a pipe/socket, because with files this normally does not
> happen.
>
[...]

As Richard stated out, this looks like a ressources-problem.

I didn't looked in detail: the Segfault seems to have to do with
Limits, so forget my other explanations. I was biased by reading your mail,
not looking in detail at the strace-stuff then.

The read might stop because no more ressources are available.
The process has a stack-limit of 8 MB.

Sorry for not reading exactly before answering your mail.

BTW: I didn't thought that OCaml can be crashed
by a non-tailrec function.

SIGSEGV can be masked/caught and I wonder,
why OCaml doesn't catch that signal by default
and gives back an exception. Wouldn't make that sense?

Ciao,
Oliver

•  11
  New Members

• Computer telephony
• Portable computer
• Computer telephony integration
• Computer telephony integration cti
• Portable computer cart

>
&gt; BTW: I didn't thought that OCaml can be crashed
> by a non-tailrec function.
>
If a non tailrec loop (or any chain of function calls, for that
matter) exhausts the stack, byte code raises a Stack_overflow
exception, but native code simply crashes with a SIGSEGV. I want to
say this might be fixed in 3.10, but don't quote me on that...

--Jonathan Bryant

On Fri, Aug 17, 2007 at 01:20:21PM +0200, Oliver Bandel wrote:
&gt; BTW: I didn't thought that OCaml can be crashed
> by a non-tailrec function.

It doesn't. If you set the stack unlimited (ulimit -s unlimited)
before running the program then OCaml will happily run it, provided
there is enough memory. It's the operating system which is killing
the program.

> SIGSEGV can be masked/caught and I wonder,
> why OCaml doesn't catch that signal by default
> and gives back an exception. Wouldn't make that sense?

It is supposed to (see the very end of this comment from Xavier Leroy:
http://caml.inria.fr/pub/ml-archives/caml-list/2002/07/b6e4e7a43ccd8fc154fb4bdd8fc4711e.en.html)
but in my experience it only works well on i386. On x86-64 you just
get a segfault.

Rich.

--
Richard Jones
Red Hat

•  11
  New Members

• Computer telephony
• Portable computer
• Computer telephony integration
• Computer telephony integration cti
• Portable computer cart

On 8/16/07, cultural_sublimation < cultural_sublimation%40yahoo.com">cultural_sublimationyahoo.com> wrote:
&gt; I should have mentioned that I had already tried the more
>; obvious solutions of gdb and strace. The former cannot be
> used, because ocamlopt does not produce debug symbols
> (there's no -g option in 3.09), and honestly, I couldn't
> really figure out what the latter produces:

You should be able to get debug symbols from ocamlopt, though they may
be terribly obfuscated. Try "-ccopt -g"...

Regards,
Chris

On Fri, Aug 17, 2007 at 09:06:23AM -0400, Jonathan Bryant wrote:
&gt; >
>; > BTW: I didn't thought that OCaml can be crashed
> > by a non-tailrec function.
> >
>; If a non tailrec loop (or any chain of function calls, for that
> matter) exhausts the stack, byte code raises a Stack_overflow
> exception, but native code simply crashes with a SIGSEGV. I want to
> say this might be fixed in 3.10, but don't quote me on that...

Not on 3.10 / x86-64. I had such a segfault only yesterday.

Rich.

--
Richard Jones
Red Hat