Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Segfault in a native code multi-threaded program
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David Mentre <David.Mentre@i...>
Subject: [Caml-list] Segfault in a native code multi-threaded program
Hello dear Camlers,

My multi-threaded program works well with the byte code compiler but
(sometimes) produces a segfault with the native code compiler. How can I
have more info to find the specific line of code that produces this
segfault? I've tried to run gdb but even when the program works until
its end, gdb is blocked.

My environment: x86 Linux.

Quoting the FAQ[1], they are several possible issues:

>   * when accessing out of range in a vector or string, when the compilers
>     does not generate bound checking (due to explicit user's request),

No. Standard compilation with all checks.

>   * when attempting to perform an illegal floating point operation
>     (division by 0), on some processors running under some OSes (e.g. alpha
>     processor under True64 Unix),

No. No floating point operations.

>   * when the program is looping and consumes the whole memory for the
>     execution stack, when the overflow check cannot detect this situation
>     (for instance, in case of a native code program running under
>     Unix),

I think no. My program is running well in byte code.

>   * when using ``magic coercion'' from the Obj module,

No. I don't use this feature.

>   * in case of erroneous usage (i.e. ill-typed usage) of marshalling
>     primitives output_value, input_value, etc,

Err, maybe. However, how to find where? And my program is working in
byte code!

>   * when calling user's defined external functions (for instance written in
>     C) and when the interface is wrong (since effective types of primitives
>     are not the types declared to the Caml compiler).

No. No external functions.

>Very often, you should use the Caml debugger to precisely find where in your
>code the error is occurring, and then correct the program.

I can't use the debugger as it does not work with multi-threaded programs.

Best regards,


 Opinions expressed here are only mine.
Bug reports:  FAQ:
To unsubscribe, mail  Archives: