Re: [Caml-list] debugger losing contact with debuggee process

Re: [Caml-list] debugger losing contact with debuggee process

[Pierre Weis]

> > The information that ocamldebug gave you is helpful : it provides the
> > mean to go back way before the bus error (Time 290000), and ensures
> > that the bus error will appear before Time 300000. To go (go) just before
> > the bus error and ask for a backtrace then (bt) is just a matter of
> > dichotomy and is very fast. Once your very near the bus error you can
> > step use instruction stepping (s) and print (p) and next event (n) to
> > understand what happens.
> 
> Yes, but then I need to start up the program again, goto time 290000 and
> step through the code until I hit the bus error. Then I need to note which
> time it happened at, reload the program again, goto that time, and do a
> backtrace.

You need not to reload the program (as mentioned in your trace the
debugger automatically reconnects to the nearest check point).

> The stepping through the code part is of concern to me. There are 10000
> events between time 290000 and 300000. Am I really expect to press "n"
> 10000 times (this is the worst case, but the expected number is 5000,
> which is still a large number for an interactive human operation)? I think
> not.

Dichotomy is there to prevent you for this fastidious task.

> So I jump forward to 295000, see if the core dump happens between
> 290000 and 295000, and repeat. Is this the suggested approach? This is a
> binary search to find the location of the fault. I like O(log n)
> operations, but I like O(1) operations better. Loading up a core dump file
> and doing a backtrace is an O(1) operation for me.

Yes, but there is no such feature in the debugger. Sorry for that.

> Another concern I have with the approach of goto time 290000 is that the
> fault is caused by an external event (receiving an RPC) so it will not
> always be at the same time. What would I do first, the goto or trigger the
> external event ? Both would seem to be problematic.

Yes, our debugger is tuned towards debugging of deterministic
programs. The first thing you should do to use it is to tune your
program to become deterministic first.

Anyhow debugging nn deterministic programs is extremely challenging
and we don't know how to do it in general. (Also our debugger is not
able to help you for that.)

> Your help is appreciated.

You're welcome.

Regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Array.resize ?

[Eray Ozkural]

On Friday 12 July 2002 19:09, Brian Rogoff wrote:
>
> I think a built in Dynarray or Vect module would probably be worthwhile.
>

Let me give it a shot, I guess I wrote that more than a couple of times in 
other languages. (/me launches konqueror to take a look at C++ code)

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] debugger losing contact with debuggee process

[Lex Stein]

Hello,

A process I am debugging has a bus error and crashes. When it crashes, it
loses contact with ocaml_debug. The output looks something like this:

calling db->put with db=3c8c0 txn=0 flags=0
Invalid argument (error number 22)
BDB: aborting transaction
Lost connection with process 3531 (active process)
between time 290000 and time 300000
Trying to recover...
Time : 290000 - pc : 59612 - module Printf
186 <|b|>let res = Buffer.contents dest in

The debugger loses contact with the debuggee process because the debuggee
has a bus error and terminates.

The information provided by ocamldebug above isn't very helpful. How do I
get a backtrace at the time of the bus error ? Something along the lines
of a bactrace on a core dump file would be great. How does one get this
information using ocamldebug ?

Sincerely,
Lex

[ I posted this question to the ocaml_beginners list. After receiving no
replies on that list after 12hours, I conclude that the people on that
list don't have the experience with ocamldebug to answer the question and
am posting it to this list. ]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] debugger losing contact with debuggee process

[Pierre Weis]

Hello,

> A process I am debugging has a bus error and crashes. When it crashes, it
> loses contact with ocaml_debug. The output looks something like this:
> 
> calling db->put with db=3c8c0 txn=0 flags=0
> Invalid argument (error number 22)
> BDB: aborting transaction
> Lost connection with process 3531 (active process)
> between time 290000 and time 300000
               ^^^^^^          ^^^^^^
These numbers are very valuable information...

> Trying to recover...
> Time : 290000 - pc : 59612 - module Printf
         ^^^^^^
> 186 <|b|>let res = Buffer.contents dest in
> 
> The debugger loses contact with the debuggee process because the debuggee
> has a bus error and terminates.
> 
> The information provided by ocamldebug above isn't very helpful. How do I
> get a backtrace at the time of the bus error ? Something along the lines
> of a bactrace on a core dump file would be great. How does one get this
> information using ocamldebug ?

The information that ocamldebug gave you is helpful : it provides the
mean to go back way before the bus error (Time 290000), and ensures
that the bus error will appear before Time 300000. To go (go) just before
the bus error and ask for a backtrace then (bt) is just a matter of
dichotomy and is very fast. Once your very near the bus error you can
step use instruction stepping (s) and print (p) and next event (n) to
understand what happens.

(Use help in the debugger to get help in the debugger.)

> Lex
> 
> [ I posted this question to the ocaml_beginners list. After receiving no
> replies on that list after 12hours, I conclude that the people on that
> list don't have the experience with ocamldebug to answer the question and
> am posting it to this list. ]

This is a bit fast: don't forget the time difference between you and
the rest of the world! Also consider that people may have something
else to do than answering to your message just now!

Sincerely,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] debugger losing contact with debuggee process

[Xavier Leroy]

> A process I am debugging has a bus error and crashes. When it crashes, it
> loses contact with ocaml_debug. The output looks something like this:
> 
> calling db->put with db=3c8c0 txn=0 flags=0
> Invalid argument (error number 22)
> BDB: aborting transaction

To complement Pierre's reply: if you do the dichotomy trick that
Pierre described, you'll probably find that the crash occurs in a 
C function (declared "external" in Caml).  Thus, you'll have to run
your program under a C debugger such as gdb.  To make this easier,
try to compile the C code with "-g", and link the Caml code with
"ocamlc -o myprog -custom -ccopt -g".  This way, you'll get a
standalone executable named myprog, with debug information attached.

Then, do "gdb myprog", and "run", until it crashes.  gdb "bt" command
will show you where the crash is located.  If it's in a C function
called directly or indirectly from OCaml's "interprete" function,
you're lucky: the error is indeed inside C code, and can be tracked
down just like you'd do for a C program.  If the crash is in
"interprete" or some other function of the OCaml runtime system,
things will be harder: presumably, some C code returned an illegal
Caml value, or messed up with the GC, causing a crash later in the
OCaml runtime system.  A good way to attack these problems is to
conduct a careful code review of the C/OCaml stub code, questioning
every single allocation and construction of OCaml values.

> [ I posted this question to the ocaml_beginners list. After receiving no
> replies on that list after 12hours, I conclude that the people on that
> list don't have the experience with ocamldebug to answer the question and
> am posting it to this list. ]

Your post is on-topic for this list.  However, your expectation that
you should get answers within 12 hours is ridiculous.  Even if you
paid a hefty support contract for a commercial development tool, you
would not get that.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners